delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/04/02/11:10:33

From: ian AT cygnus DOT com (Ian Lance Taylor)
Subject: Re: Linker switches [ was: Re: API's that certainly do work. ]
2 Apr 1997 11:10:33 -0800 :
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <9704021617.AA21329.cygnus.gnu-win32@tweedledumb.cygnus.com>
Original-To: marcus AT bighorn DOT dr DOT lucent DOT com
Original-Cc: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

In gnu-win32 marcus AT bighorn DOT dr DOT lucent DOT com writes:

>I'd have to agree with this.  It would also be very nice for ld to procude
>the .reloc section directly instead of having to make a pre-pass and working
>with dlltool to produce it.  Conceptually it isn't difficult, but there may
>be some design issues with ld that make it difficult (the size of all segments
>[including .reloc] must be known before output is started, but the .reloc
>data is generated as a byproduct of the output processing, I think)  I
>don't think that it is necessary to eliminate dlltool, but if the process
>for creating a dll is made reliable and more intuitive, I'm all for it.

All shared library schemes must generate some sort of relocation
section after reading the input files but before writing the output
file.  The GNU linker, which fully supports shared libraries on SunOS,
AIX, and several ELF based systems, solves this by using a
size_dynamic_sections routine which is called by the emulation code.
See, for example, ld/emultempl/elf32.em, and the functions which it
calls in bfd/elflink.h.

Ian
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019