Re: Crash with libtool geneated import *.libs for dll(s) in MSVC++ Release target (Debug OK)

[Peter Rosin]

Den 2011-04-02 10:25 skrev Ralf Wildenhues:
> Hello Francesco,
> 
> thanks for the nice bug report.
> 
> * Francesco Pretto wrote on Fri, Apr 01, 2011 at 05:28:43PM CEST:
>> I having a crash with import *.libs generated by libtool and used in
>> MSVC++ 2008 SP1, 32 bit compilation, Release target. The crash is a
>> page fault that triggers during DLL_PROCESS_ATTACH. I can reproduce
>> always and other [1] users have noticed the problem.
> 
>> Please, ask me if you need more info.
> 
> IIUC this is a bug in dlltool, and exposed by using libtool because that
> invokes dlltool, right?  Has there been any analysis of the nature of
> the dlltool bug?  We should get that reported to the binutils developers
> so it can be fixed upstream.
> 
> Unfortunately, I'm not really in the position to do this analysis myself
> (both due to time constraints and lack of w32 experience), so I'll have
> to defer to my more proficient w32 fellows here.

Libtool uses dlltool only to dig out info on what dlls a specific import
library pulls in, and only when dlltool is new enough.

The thread over at ffmpeg speaks about using "the lib tool" (I think
lib.exe is what is referred to and not Libtool) instead of "dllwrap" to
create the .lib files and that someone at #ffmpeg-devel seemed hard
pressed to stay with "dlltool".

Since Libtool uses neither "dlltool", "the lib tool" nor "dllwrap" for
*creating* any library and the library consumer is not using Libtool, I
fail to see how Libtool is implicated at all.

My guess is that ffmpeg has added some extra Makefile rule to create
.lib files for their non-GCC customers, using the .dll.a files and/or
the .dll files created by Libtool as input.

So, I don't really see how Libtool is exposing any bug here, given that
I have guessed correctly in all of the above of course.  To me, this
seems to be a bug involving binutils and/or ffmpeg, but not Libtool.

Cheers,
Peter