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 <ian AT cygnus DOT com>, 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 <jont AT harlequin DOT co DOT uk>
 > 
 >    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".

- Raw text -