This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Need help figuring out DLL load problem
- From: Danny Backx <danny dot backx at scarlet dot be>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: binutils at sourceware dot org
- Date: Wed, 05 Aug 2009 19:54:11 +0200
- Subject: Re: Need help figuring out DLL load problem
- References: <1248970879.5537.415.camel@pavilion> <4A71DFC8.6060908@gmail.com> <1248976791.5537.420.camel@pavilion> <4A71FAF5.5000908@gmail.com> <1249215774.5537.438.camel@pavilion> <4A78AE56.2060300@gmail.com>
- Reply-to: danny dot backx at scarlet dot be
On Tue, 2009-08-04 at 22:55 +0100, Dave Korn wrote:
> Danny Backx wrote:
> > This appears to indicate different input symbol lists. The difference
> > contains one of the symbols we're chasing : __ZNSt8ios_base4InitC1Ev .
> >
> > Is this meaningful, or is another part of the output key to the answer ?
>
> Well, it's at the root of why pe_find_data_imports thinks it's dealing with a
> data export. LD is processing the list of undefined symbols. Any that it finds
> are undefined, and for which there is an __imp_* equivalent, it assumes are data
> imports that need a fixup. This is the case for __ZNSt8ios_base4InitC1Ev, which
> is undefined, but __imp___ZNSt8ios_base4InitC1Ev is defined, so it gets a fixup
> applied.
>
> It should not be the case that __ZNSt8ios_base4InitC1Ev is undefined in the
> first place, because there should be a jump stub by that name in
> libstdc++.dll.a, which jumps through the __imp__ version. (This is why it's
> reasonable to infer that if the symbols is still undefined, it must be a data
> symbol; function exports all have the jump stub, under the non-prefixed names of
> their imports, and so should have been resolved; data items don't have jump
> stubs, so anything still unresolved must be a data item.)
>
> So, next question: what's in your libstdc++.dll.a that relates to
> __ZNSt8ios_base4InitC1Ev? Here's an example from my cygwin install of tracking
> it down:
>
> > $ nm /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a | \
> > grep -C6 __ZNSt8ios_base4InitC1Ev
> > d001743.o:
> > 00000000 i .idata$4
> > 00000000 i .idata$5
> > 00000000 i .idata$6
> > 00000000 i .idata$7
> > 00000000 t .text
> > 00000000 T __ZNSt8ios_base4InitC1Ev
> > U __head_cygstdc___6_dll
> > 00000000 I __imp___ZNSt8ios_base4InitC1Ev
Yes, there is a problem in libstdc++.dll.a . And there's a difference
between my ARM version (looks like your cygwin version), and my x86
version. The symbol you wanted me to look up is missing :
pavilion: {482} i386-mingw32ce-nm libstdc++.dll.a >x
pavilion: {483} fgrep -C9 __ZNSt8ios_base4InitC x
00000000 I __nm___ZNSt8ios_base4InitD1Ev
d002746.o:
00000000 i .idata$4
00000000 i .idata$5
00000000 i .idata$6
00000000 i .idata$7
00000000 t .text
U __head_libstdc___6_dll
00000000 I __imp___ZNSt8ios_base4InitC2Ev
00000000 I __nm___ZNSt8ios_base4InitC2Ev
d002745.o:
00000000 i .idata$4
00000000 i .idata$5
00000000 i .idata$6
00000000 i .idata$7
00000000 t .text
U __head_libstdc___6_dll
00000000 I __imp___ZNSt8ios_base4InitC1Ev
00000000 I __nm___ZNSt8ios_base4InitC1Ev
d002744.o:
00000000 i .idata$4
00000000 i .idata$5
00000000 i .idata$6
00000000 i .idata$7
00000000 t .text
U __head_libstdc___6_dll
00000000 I __imp___ZNSt8ios_base4Init20_S_synced_with_stdioE
pavilion: {484}
These are the commands used (extracted from the make process) to build
this :
i386-mingw32ce-dlltool --output-def libstdc++.def \
--export-all /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++.a
i386-mingw32ce-g++ --shared -o libstdc++-6.dll \
-Wl,--out-implib,libstdc++.dll.a libstdc++.def \
/opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++.a -lgcc
It is the g++ command that creates the libstdc++.dll.a file. Running
this with "-v" gives this output :
Using built-in specs.
Target: i386-mingw32ce
Configured
with: /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-4.4.0/configure --with-gcc --with-gnu-ld --with-gnu-as --target=i386-mingw32ce --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --prefix=/opt/x86mingw32ce --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-multilib --disable-interwork --without-newlib --enable-checking --with-headers --disable-__cxa_atexit
Thread model: win32
gcc version 4.4.0 (GCC)
COMPILER_PATH=/opt/x86mingw32ce/libexec/gcc/i386-mingw32ce/4.4.0/:/opt/x86mingw32ce/libexec/gcc/i386-mingw32ce/4.4.0/:/opt/x86mingw32ce/libexec/gcc/i386-mingw32ce/:/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/:/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/:/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/../../../../i386-mingw32ce/bin/
LIBRARY_PATH=/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/:/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/../../../../i386-mingw32ce/lib/
COLLECT_GCC_OPTIONS='-shared' '-o' 'libstdc++-6.dll' '-v'
'-shared-libgcc' '-mtune=i386'
/opt/x86mingw32ce/libexec/gcc/i386-mingw32ce/4.4.0/collect2 --shared
-Bdynamic -e _DllMainCRTStartup -o libstdc
++-6.dll /opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/../../../../i386-mingw32ce/lib/dllcrt3.o -L/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0 -L/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/../../../../i386-mingw32ce/lib --out-implib libstdc++.dll.a libstdc++.def /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++.a -lgcc -lstdc++ -lmingw32 -lgcc_s -lgcc -lceoldname -lmingwex -lcoredll -lmingw32 -lgcc_s -lgcc -lceoldname -lmingwex /opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/crtend.o
Creating library file: libstdc++.dll.a
I thought maybe I needed to replace the libstdc++.a by all of its member
files extracted into a directory. That made no difference though.
The original libstdc++.a file does appear to contain the right things
(meaning ios_init.o is indeed in it) :
pavilion: {531}
i386-mingw32ce-nm /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++.a > y
pavilion: {532} fgrep -C4 __ZNSt8ios_base4InitC y
U __ZNSt6localeD1Ev
00000000 T __ZNSt8ios_base15sync_with_stdioEb
U __ZNSt8ios_base4Init11_S_refcountE
U __ZNSt8ios_base4Init20_S_synced_with_stdioE
00000000 T __ZNSt8ios_base4InitC1Ev
00000000 T __ZNSt8ios_base4InitC2Ev
00000000 T __ZNSt8ios_base4InitD1Ev
00000000 T __ZNSt8ios_base4InitD2Ev
U __ZNSt8ios_baseC2Ev
U
__ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E
pavilion: {533}
How does collect2 (this is ld, right?) create this libstdc++.dll.a ? The
message "Creating library file" appears to come from
binutils/ld/pe-dll.c .
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info