From: DJ Delorie <dj@delorie.com>
To: paul-ml@is.lg.ua
Cc: cygwin@sourceware.cygnus.com
Subject: Re: ld, dlls, and windows libraries
Date: Sat, 13 Feb 1999 09:52:00 -0000 [thread overview]
Message-ID: <199902131751.MAA26487@envy.delorie.com> (raw)
In-Reply-To: < 1809.990213@is.lg.ua > (message from Paul Sokolovsky on Sat, 13Feb 1999 19:25:34 +0200)
> 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.
WARNING: multiple messages have this Message-ID
From: DJ Delorie <dj@delorie.com>
To: paul-ml@is.lg.ua
Cc: cygwin@sourceware.cygnus.com
Subject: Re: ld, dlls, and windows libraries
Date: Sun, 28 Feb 1999 23:02:00 -0000 [thread overview]
Message-ID: <199902131751.MAA26487@envy.delorie.com> (raw)
Message-ID: <19990228230200.HhgK32bsQJJEXPSvuqJVr0b1RZWMCcvnwkg7_b5WT5k@z> (raw)
In-Reply-To: <1809.990213@is.lg.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.
next prev parent reply other threads:[~1999-02-13 9:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-12 8:40 John Fortin
[not found] ` < 36C4582C.A302D915@ibm.net >
1999-02-12 9:56 ` Mumit Khan
1999-02-12 10:06 ` John Fortin
1999-02-28 23:02 ` John Fortin
[not found] ` < Pine.SUN.3.93.990212113933.18731B-100000@modi.xraylith.wisc.edu >
1999-02-12 16:53 ` Geoffrey Noer
1999-02-28 23:02 ` Geoffrey Noer
1999-02-13 9:28 ` Re[2]: " Paul Sokolovsky
[not found] ` < 1809.990213@is.lg.ua >
1999-02-13 9:52 ` Mumit Khan
1999-02-28 23:02 ` Mumit Khan
1999-02-13 9:52 ` DJ Delorie [this message]
[not found] ` < 199902131751.MAA26487@envy.delorie.com >
1999-02-13 10:02 ` Mumit Khan
1999-02-13 10:40 ` Re[2]: " Paul Sokolovsky
[not found] ` < 13857.990213@is.lg.ua >
1999-02-13 10:48 ` DJ Delorie
1999-02-28 23:02 ` DJ Delorie
1999-02-28 23:02 ` Re[2]: " Paul Sokolovsky
1999-02-28 23:02 ` Mumit Khan
1999-02-28 23:02 ` DJ Delorie
1999-02-28 23:02 ` Re[2]: " Paul Sokolovsky
1999-02-28 23:02 ` Mumit Khan
1999-02-28 23:02 ` John Fortin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199902131751.MAA26487@envy.delorie.com \
--to=dj@delorie.com \
--cc=cygwin@sourceware.cygnus.com \
--cc=paul-ml@is.lg.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).