From: Paul Sokolovsky <paul-ml@is.lg.ua>
To: Mumit Khan <khan@xraylith.wisc.EDU>, DJ Delorie <dj@delorie.com>
Cc: cygwin@sourceware.cygnus.com
Subject: Re[2]: ld, dlls, and windows libraries
Date: Sun, 28 Feb 1999 23:02:00 -0000 [thread overview]
Message-ID: <13857.990213@is.lg.ua> (raw)
Message-ID: <19990228230200.UBmzd54-R32nv4Pwti5oKPouucI4VCC1OEnd3QuEapo@z> (raw)
In-Reply-To: <199902131802.MAA20124@modi.xraylith.wisc.edu>
Hello Mumit,
Mumit Khan <khan@xraylith.wisc.EDU> wrote:
MK> DJ Delorie <dj@delorie.com> writes:
>> 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).
[]
>> 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).
What we have now:
Dlltool can automatically make .def file from objects which are
supposed to go to dll, but that def has no DATA keyword for data, so
all by default treated as code, which in result give incorrect imlib.
What is going to be when DJ's work's out:
Ignoring data at all.
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).
I'm sorry if I make incoreect implications and/or there're other
factors which make described impossible. I'd appreciate if you could
explain this or point to information about.
MK> Regards,
MK> Mumit
Best regards,
Paul mailto:paul-ml@is.lg.ua
next prev parent reply other threads:[~1999-02-28 23:02 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
[not found] ` < 199902131751.MAA26487@envy.delorie.com >
1999-02-13 10:02 ` Mumit Khan
1999-02-13 10:40 ` Paul Sokolovsky [this message]
[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=13857.990213@is.lg.ua \
--to=paul-ml@is.lg.ua \
--cc=cygwin@sourceware.cygnus.com \
--cc=dj@delorie.com \
--cc=khan@xraylith.wisc.EDU \
/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).