Delivered-To:	listarch-cygwin AT sourceware DOT cygnus DOT com
Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Date:	Sat, 13 Feb 1999 12:51:58 -0500
Message-Id:	<199902131751.MAA26487@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	paul-ml AT is DOT lg DOT ua
CC:	cygwin AT sourceware DOT cygnus DOT com
In-reply-to:	<1809.990213@is.lg.ua> (message from Paul Sokolovsky on Sat, 13
	Feb 1999 19:25:34 +0200)
Subject:	Re: ld, dlls, and windows libraries
References:	<Pine DOT SUN DOT 3 DOT 93 DOT 990212113933 DOT 18731B-100000 AT modi DOT xraylith DOT wisc DOT edu> <1809 DOT 990213 AT is DOT lg DOT ua>

> MK> When DJ's excellent work on ld is released, you'll be able to do:
> MK>   $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
> 
>   Wow! How long to wait for this?

It's in our master sources, it's all a matter of when we do the next
full beta.  I'm not sure about the "--export-all" part; you may need
to do "-Wl,--export-all" as that's a linker-specific option.  Unless
someone wants to get it into egcs (hint).

> MK> The --export-all exports all the non-static symbols as done on most 

It's *supposed* to only export non-static functions, not non-static
data.

> MK> Unix systems. If you want to restrict the exports, you have two choices:
> 
>   And what about implibs? Is there a chance that they will be produced
> with gcc too, so procedure and data exports will be properly
> distinguished? That's the thing which causes most pain with gnu-win32
> tools now, imho, - suffering an access violation when, due to automatically
> produced def, which treats all exports as code, some fucnction fetches jump
> instruction instead of data.

The changes I did to ld allow the following cool new features:

* ld can produce a DLL instead of an EXE.

* ld can produce the implib at the same time it produces the dll.

* You can list .def files on the command lines just like objects when
  creating dlls, or the IMPORTS section can be used instead of linking
  against a dll (i.e. a def file's IMPORTS can replace an implib).

* You can tell ld to *produce* a .def file (for --export-all and
  attribute()) when it produces the dll.

* You can list a DLL on the command line just like a library (it
  synthesizes the implib internally).

* "ld --help" lists all the nt-specific options.

As far as data/code differences, you MUST tag all your imported data
as imported (attribute((dllimport))) in your header files for gcc to
produce the correct code to access them.  Even if ld did this right (I
don't think it does), it would only change your error from a segfault
to an unresolved external.

If anyone wants to test this ld, or submit additions to it, mail me
personally.  Please include a note about what you're thinking of
doing, too.

- Raw text -