This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need help figuring out DLL load problem


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]