From: jont AT harlequin DOT co DOT uk (Jon Thackray) Subject: Re: Trying to remake dlltool 9 Jul 1997 09:22:00 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199707091539.QAA13796.cygnus.gnu-win32@zaphod.long.harlequin.co.uk> References: <199707090927 DOT KAA12556 AT zaphod DOT long DOT harlequin DOT co DOT uk> <199707091513 DOT LAA27626 AT subrogation DOT cygnus DOT com> Original-To: Ian Lance Taylor , gnu-win32 AT cygnus DOT com In-Reply-To: <199707091513.LAA27626@subrogation.cygnus.com> Original-Sender: owner-gnu-win32 AT cygnus DOT com Ian Lance Taylor writes: > Date: Wed, 9 Jul 1997 10:27:21 +0100 > From: Jon Thackray > > ian AT cygnus DOT com writes: > > >I am trying to rebuild dlltool and am running into problems. The > > >reason I am trying to rebuild it is that it produces symbols with one > > >too many _ characters at the start, and these break the link step. > > > > This problem is almost certainly not in dlltool. > > Do you have a suggestion as to where it might be? The scenario is, I > have a .lib file and some .obj files I wish to link against it. Using > link, this all proceeds correctly. Using nm to get the defined symbols > from the .lib file, and then using dlltool to build a .a from these, > then using ld, the link fails because the __imp symbols can't be > matched. Using nm on the .obj files and the .a file indicates that all > the __imp symbols match between one and the other, except that the > ones in the .a file have an extra _ at the start of each one. > > I didn't realize that you only meant the __imp symbols. I agree; that > problem probably is in dlltool. Actually, some of the others don't match either. But they all fail for the same reason, one too many _ in the names produced by dlltool. > What do the symbols look like in .lib files generated by your other > tool? Can you give a sample of nm output, for example? I'll include some sample output from failures at the end. According to nm, the symbols in .lib files are of the form foo and __imp_foo The corresponding symbols in the .a file produced by dlltool are reported by nm to be of the form _foo and ___imp_foo As far as I can see, this is caused by the section in dlltool containing the following:- rvaafter (machine) int machine; { switch (machine) { case MARM: return ""; case M386: return "_"; case MPPC: return ""; } return ""; } Changing the line return "_" to return "" fixes that problem for me. Then getting the object files and .a files in the right order in the link command produces a clean link. Using the same command, but with a ..a file generated by the released dlltool fails with undefined symbols reported as > I don't want all the tools, and I don't even have room to unpack the > entire set. Can I persuade configure to work only for the bits I need > (ie bfd, libiberty, dlltool). > > configure will work on whatever subdirectories it sees. I've discovered this now thanks. > Besides the ones you mention, you'll probably also need the include > directory. Yes, found that out. Sample output:- First, see what the object file asks for. nm j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj | grep KPfalseYinternalVdylan U __imp_KPfalseYinternalVdylan Now see what the .lib file as provided by link gives. nm dylan.lib | grep KPfalseYinternalVdylan 00000000 T KPfalseYinternalVdylan 00000000 ? __imp_KPfalseYinternalVdylan Now see what the .a file produced by the modified dlltool offers. nm libdylan.a | grep KPfalseYinternalVdylan 00000000 T KPfalseYinternalVdylan 00000000 ? __imp_KPfalseYinternalVdylan Now see what the .a file produced by the original dlltool offers. nm libdyl.a | grep KPfalseYinternalVdylan 00000000 T _KPfalseYinternalVdylan 00000000 ? ___imp_KPfalseYinternalVdylan Now see what happens when we link against libdylan.a (produced by modified dlltool) ld -T i386pe.scr --dll -shared -Bdynamic -E -e _DylanDllEntry AT 12 -o threads.dll --traditional-format j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj j:/releases/pentium-kan/build/x86-win32/threads/threads-library.obj j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj -L. -ldylan And now when we link against libdyl.a (produced by original dlltool) ld -T i386pe.scr --dll -shared -Bdynamic -E -e _DylanDllEntry AT 12 -o threads.dll --traditional-format j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj j:/releases/pentium-kan/build/x86-win32/threads/threads-library.obj j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj -L. -ldyl j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj(.text+0x8):/amd/propos/u/: undefined reference to `_imp_KPfalseYinternalVdylan' j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj(.text+0x13):/amd/propos/u/: undefined reference to `_imp_KPtrueYinternalVdylan' j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj(.text+0x1e):/amd/propos/u/: undefined reference to `Init_dylan_' j:/releases/pentium-kan/build/x86-win32/threads/_glue.obj(.dyfix$m+0x5):/amd/propos/u/: undefined reference to `_imp_KPfalseYinternalVdylan' j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj(.text+0x12):dylan-support.: undefined reference to `primitive_fixup_imported_dylan_data' j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj(.text+0x35):dylan-support.: undefined reference to `primitive_register_traced_data' j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj(.text+0x79):dylan-support.: undefined reference to `primitive_call_first_dylan_iep' j:/releases/pentium-kan/lib/pentium-run-time/dylan-support.obj(.text+0x9f):dylan-support.: undefined reference to `dylan_init_thread_local' - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".