[Mingw-users] The procedure entry point _ftelli64 could not be located in the dynamic link library msvcrt.dll

[Ray Satiro]

For projects that use autoconf they typically do something like this for <function>:
AC_CHECK_FUNCS([<function>])
and that results in HAVE_<function>
In wget there is:
  AC_CHECK_FUNCS([_ftelli64])
http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz

Which results in configure doing something like this
main ()
{
return _ftelli64 ();
return 0;
}
gcc a.c
In older MinGW compile failure, in newer success (ie HAVE__FTELLI64). So during compile in newer it thinks _ftelli64() is available but not necessarily.

Yesterday I did a fresh install of MinGW using mingw-get-setup.exe in an up to date Vista SP2 x86 VM and its msvcrt does not contain _ftelli64, for example. There is some change that has resulted in programs that compile fine but give an error when they are actually run. I compiled wget fine but when I ran it I saw this:

The procedure entry point _ftelli64 could not be located in the dynamic link library msvcrt.dll

It seems to me the change can cause a lot of problems and result in compiled programs that won't run on XP, Vista. Do you have any advice on how to deal with this issue?

Also, here is some related background I found from searching the web:

Late 2012 change to remove the version check before some function prototypes like _ftelli64
http://sourceforge.net/mailarchive/message.php?msg_id=29575958
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/73f6ac0c5a3c485b0bcea20e05f06dc9f705bf6c

Late 2013 bug listed as fixed regarding _ftelli64 _fseeki64.
http://sourceforge.net/p/mingw/bugs/2021
Not sure if/how that relates to a default install of MinGW, what I assume most users will have.


Thanks and pardon any formatting issues as I'm still adjusting to the new Yahoo mail.. although I'm sending this in plaintext so it should be ok...

[Keith Marshall]

Post by Ray Satiro
For projects that use autoconf they typically do something like this
for <function>: AC_CHECK_FUNCS([<function>]) and that results in
HAVE_<function> In wget there is: AC_CHECK_FUNCS([_ftelli64])
http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz
Which results in configure doing something like this main () { return
_ftelli64 ();

Which, if the prototype were properly #included, would result in a
compile time error; (yes, I know autoconf checks deliberately avoid
#including appropriate prototypes).

Post by Ray Satiro
return 0; } gcc a.c In older MinGW compile failure, in newer success
(ie HAVE__FTELLI64). So during compile in newer it thinks _ftelli64()
is available but not necessarily.
Yesterday I did a fresh install of MinGW using mingw-get-setup.exe
in an up to date Vista SP2 x86 VM and its msvcrt does not contain
_ftelli64, for example. There is some change that has resulted in
programs that compile fine but give an error when they are actually
run.

This seems to be broken, in mingwrt-4.0, with...

Post by Ray Satiro
The procedure entry point _ftelli64 could not be located in the
dynamic link library msvcrt.dll

...this consequence.

Post by Ray Satiro
It seems to me the change can cause a lot of problems and result in
compiled programs that won't run on XP, Vista. Do you have any advice
on how to deal with this issue?

I agree. As to advice...

Post by Ray Satiro
Late 2012 change to remove the version check before some function prototypes like _ftelli64
http://sourceforge.net/mailarchive/message.php?msg_id=29575958
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/73f6ac0c5a3c485b0bcea20e05f06dc9f705bf6c

About which, you may note from the discussion, I had grave reservations
at the time.

Post by Ray Satiro
Late 2013 bug listed as fixed regarding _ftelli64 _fseeki64.
http://sourceforge.net/p/mingw/bugs/2021 Not sure if/how that relates
to a default install of MinGW, what I assume most users will have.

It is "fixed" on the 4.1-dev branch of the git repository, but not on
master, (where "fixed" refers to the adoption of the function aliases);
this suggests that the fix will be delayed until the formal release of
mingwrt-4.1. Perhaps Earnie could comment on his decision to delay
publication of this solution, when, as you've noted, this bug can cause
critical failures in already existing code. Furthermore, he might also
confirm that, in addition to providing the aliases, he has removed the
public symbols from the libmsvcrt.a import library, (because, we don't
want autoconf to see them there), and replaced them with wrapper stubs
for the alias code, in libmingwex.a, (which he likely hasn't).

For a solution today, your best bet may be to clone the git repository,
https://sourceforge.net/p/mingw/mingw-org-wsl/, check out, build, and
install the 4.1-dev branch for your own immediate use.

Post by Ray Satiro
Thanks and pardon any formatting issues as I'm still adjusting to the
new Yahoo mail.. although I'm sending this in plaintext so it should
be ok...

Not entirely; it isn't consistent, but some paragraphs are wrapping
sensibly, while many are not. If you could fix it, so that all wrap at
around 72 characters, this would be appreciated.

[Keith Marshall]

Post by Ray Satiro
AC_CHECK_FUNCS([<function>])
and that results in HAVE_<function>
AC_CHECK_FUNCS([_ftelli64])
http://alpha.gnu.org/gnu/wget/wget-1.14.96-38327.tar.gz
Which results in configure doing something like this
main ()
{
return _ftelli64 ();
return 0;
}

FWIW, if I compile this variant of the above, against current mingwrt,
(or rather, to be precise, 4.0-dev HEAD):

$ cat foo.c
#include <stdio.h>

int main()
{ __int64 i = _ftelli64( (FILE *)(0) );
return i - i;
}

I see:

$ mingw32-gcc -c -Wall foo.c
$ mingw32-nm foo.o
00000000 b .bss
00000000 d .data
00000000 t .text
U ___main
U __alloca
U __ftelli64
00000000 T _main

Naturally, this would lead to...

Post by Ray Satiro
The procedure entry point _ftelli64 could not be located in the
dynamic link library msvcrt.dll

...this, when the system MSVCRT.DLL does not provide _ftelli64(). OTOH,
if I substitute just stdio.h from 4.1-dev HEAD, I see:

$ mingw32-gcc -c -Wall foo.c
$ mingw32-nm foo.o
00000000 b .bss
00000000 d .data
00000000 t .text
U ___main
U __alloca
U __fileno
U __telli64
00000000 T _main

This eliminates the dependency on _ftelli64(), in favour of _fileno()
and _telli64(), both of which, according to MSDN, should be supported by
all versions of MSVCRT.DLL in all versions of Windows from Win98 and
WinNT, (which I assume means NT4), onwards. However, I cannot be sure
that substitution of only this one file will not introduce some header
vs. library inconsistency, for more comprehensive usage.