From: DJ Delorie <dj@delorie.com>
To: paul-ml@is.lg.ua
Cc: khan@xraylith.wisc.EDU, cygwin@sourceware.cygnus.com
Subject: Re: ld, dlls, and windows libraries
Date: Sat, 13 Feb 1999 10:48:00 -0000 [thread overview]
Message-ID: <199902131848.NAA26824@envy.delorie.com> (raw)
In-Reply-To: < 13857.990213@is.lg.ua > (message from Paul Sokolovsky on Sat, 13Feb 1999 20:35:21 +0200)
> >> It's *supposed* to only export non-static functions, not non-static
> >> data.
>
> But what about data? There's really LOT of libraries which use data
> interface in API (most GNU libs do that too - just count: readline,
> bfd...). It would be very nice if they can be seamlessly (without
> changing source, adding defs, etc.) compiled as dll (and has correct
> implib, too).
You just can't use the --export-all function for those. *All* data
exported by the dll *must* be tagged as __attribute__((dllimport)) or
gcc will not produce the correct code for it. If you're tagging it
anyway, ld will notice that and export it - even without the
--export-all option. The only time --export-all would make a
difference with data is when it turns an undefined reference into an
incorrect reference. You'd be better off without it!
Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS. The linker can't
get it right without gcc's help, and if it has gcc's help, it doesn't
need --export-all to finish the job.
> But what I argue is that it's possible on object file level to
> distinguish data and code and to produce correct implibs
> automatically - just because COFF symbol has code/data attribute (not
> counting that it may be inferred from the section symbol in).
True, but gcc will not use the implib correctly. You don't understand
what gcc has to go through to access data in a dll - IT'S NOT A LINKER
PROBLEM. Gcc has to produce *different* code depending on whether
data is local or imported - it can't use a link-time thunk like it can
for functions. GCC MUST KNOW ABOUT IMPORTED DATA. When it does, it
will tell the linker how to deal with it. There is nothing the linker
can do about it, so there is no reason to provide linker-specific
options to automatically handle data.
WARNING: multiple messages have this Message-ID
From: DJ Delorie <dj@delorie.com>
To: paul-ml@is.lg.ua
Cc: khan@xraylith.wisc.EDU, cygwin@sourceware.cygnus.com
Subject: Re: ld, dlls, and windows libraries
Date: Sun, 28 Feb 1999 23:02:00 -0000 [thread overview]
Message-ID: <199902131848.NAA26824@envy.delorie.com> (raw)
Message-ID: <19990228230200.GWANBcz3psCOpiqRNKp_5tnE0VB--Lg1jafVTI2yvwI@z> (raw)
In-Reply-To: <13857.990213@is.lg.ua>
> >> It's *supposed* to only export non-static functions, not non-static
> >> data.
>
> But what about data? There's really LOT of libraries which use data
> interface in API (most GNU libs do that too - just count: readline,
> bfd...). It would be very nice if they can be seamlessly (without
> changing source, adding defs, etc.) compiled as dll (and has correct
> implib, too).
You just can't use the --export-all function for those. *All* data
exported by the dll *must* be tagged as __attribute__((dllimport)) or
gcc will not produce the correct code for it. If you're tagging it
anyway, ld will notice that and export it - even without the
--export-all option. The only time --export-all would make a
difference with data is when it turns an undefined reference into an
incorrect reference. You'd be better off without it!
Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS. The linker can't
get it right without gcc's help, and if it has gcc's help, it doesn't
need --export-all to finish the job.
> But what I argue is that it's possible on object file level to
> distinguish data and code and to produce correct implibs
> automatically - just because COFF symbol has code/data attribute (not
> counting that it may be inferred from the section symbol in).
True, but gcc will not use the implib correctly. You don't understand
what gcc has to go through to access data in a dll - IT'S NOT A LINKER
PROBLEM. Gcc has to produce *different* code depending on whether
data is local or imported - it can't use a link-time thunk like it can
for functions. GCC MUST KNOW ABOUT IMPORTED DATA. When it does, it
will tell the linker how to deal with it. There is nothing the linker
can do about it, so there is no reason to provide linker-specific
options to automatically handle data.
next prev parent reply other threads:[~1999-02-13 10:48 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 ` DJ Delorie
[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 [this message]
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-13 9:52 ` Re[2]: " Mumit Khan
1999-02-28 23:02 ` Mumit Khan
1999-02-28 23:02 ` 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=199902131848.NAA26824@envy.delorie.com \
--to=dj@delorie.com \
--cc=cygwin@sourceware.cygnus.com \
--cc=khan@xraylith.wisc.EDU \
--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).