Trying to remake dlltool

Wed Jul 9 08:43:00 GMT 1997

Ian Lance Taylor writes:
 > Date: Wed, 9 Jul 1997 10:27:21 +0100
 > From: Jon Thackray <jont@harlequin.co.uk>
 > 
 > ian@cygnus.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@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@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@cygnus.com" with one line of text: "help".