Re: ld, dlls, and windows libraries

[DJ Delorie <dj@delorie.com>]

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