From:	Nick DOT Ing-Simmons AT tiuk DOT ti DOT com
Subject:	ld / dlltool
9 Dec 1997 07:12:41 -0800 :
Message-ID:	<199712091434.OAA16836.cygnus.gnu-win32@pluto.tiuk.ti.com>
To:	GNU-Win32 AT cygnus DOT com
Cc:	j DOT j DOT vanderheijden AT student DOT utwente DOT nl

I have successfully built perl5.004_55+ using the 'native' Mingw32
gcc/binutils port from: 

 http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/

It was fairly easy except for the business with dlltool.

To build a loadable dll for a perl extension takes two runs of dlltool
and two of ld. 

To build the main perl.dll also uses two passes by generating the import
library on one of the other two.

This is clumsy at best, the import library generation in particular takes
a very long time for the large number of symbols perl exports. 
(Just about doubles the build time) - and they will nearly always be used
together so separate .o file for each symbol seems excessive.

Why cannot the linker do the rellocation stuff itself, why does it need
this bag-on-the-side?  If linker had to be modified to accept and output 
--dll and --base-file why could it not be taught to write the .reloc section?    


The other stuff (building the source of export module from .def file, and
invoking the assembler) could easily be done with a perl script.
(Indeed you could also do the --base-file -> reloc source in perl too
 if it really must be done that way.)
For some reason dlltool did not like the .def file used for VC++/Borland
but it was not clear from the 'syntax error line 1' type message what 
was wrong.

I would be willing to assist in/perform or make the effort to clean this up, 
but would like to know why it was done this way rather than as part of the 
bfd port for the win32 object format.

--
Nick Ing-Simmons

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