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

[Keith M. <kei...@us...>]

On 05/11/13 07:46, Ray Satiro wrote:
> 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).

> 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...

> 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

...this consequence.

> 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...

> 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

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

> 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.

> 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.

-- 
Regards,
Keith.