Re: Trying to remake dlltool

[Jon Thackray <jont at harlequin dot co dot uk>]

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".