Mail Archives: cygwin/2000/04/30/13:31:10
Hello libtool,
This is a forwarded message
From: Paul Sokolovsky
To: DJ Delorie
Date: Saturday, April 29, 2000, 1:43:49 PM
Subject: Question about binutils of cygwin 1.1.0
===8<==============Original message text===============
Hello DJ,
O, I used to ask Mumit Khan why he distributes such outdated,
19990818 binutils for mingw32, and got answer that there's bad
attitudes of binutils maintainers towards pe frontend. Now, when
official Cygnus release contains the same, I see that's true...
Well, what I want to ask whether cygwin binutils are built from
Mumit's sources, i.e. contain additional (required!) patches. My tests
shows that yes. Asking just to be sure.
Best regards,
Paul
===8<===========End of original message text===========
This is a forwarded message
From: DJ Delorie
To: Paul Sokolovsky
Date: Saturday, April 29, 2000, 3:43:12 PM
Subject: Question about binutils of cygwin 1.1.0
===8<==============Original message text===============
The binutils and gcc on sourceware *are* from Mumit.
===8<===========End of original message text===========
With this I would like to confirm that current releases of major
gnu-win32 targets:
- Cygwin 1.1.0
- Mingw32 2.95.2-1
contain support, in binutils and gcc, for the following features
crucial for easy and robust creation of dynamically-linked libraries
(DLLs):
- One-pass link supported directly by ld, with standard -shared option
enabling it.
- Distinguishing between code and data symbols both when creating
module definition file (def) from set of object files and when
creating import library (implib) from def (as well as for one-step
process, of course). While ld -shared brings great convenience to
building of dlls, it doesn't offer anything new technologically - all
its functionality was supported before by dllwrap. However, proper
handling of data symbols is presupposition to both robust procedure of
making some code dll-aware and correct working of resulting code.
Please see following links for more information:
http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00719.html
http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00730.html
http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00734.html
http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00763.html
http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00779.html
http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00781.html
Having said that, it should be noted that both novelties have
misfeatures which may require workarounds, sometimes
human-attention-requiring. I'll try to summarize ones I'm aware of:
ld -shared
----------
1. ld is quite smart (thanks, DJ): when object files it links do not
contain explicit dllexported symbols, it automagically exports all
symbols, as if --export-all option were given. The problem here is
that such case it doesn't export any data symbols - neither with this
automagical feature, nor with explicit --export-all. Reason behind is
understandable - using data symbols requires additional coping with
them after dll was created, so let's pretend they don't exist at all.
Failure here is that such policy disallow coping with data symbols *at
all*. What surprises me is that it's DJ Delorie who did it that way (
;-) ). I was able to come up with following workaround: create def
with dlltool and then feed it to ld -shared. However, ld when given
def with ordinals (the way dlltool produces it), makes broken dlls.
So, it needs to produce def, filter it off ordinals, and then give it
to ld.
2. There were reported pathological cases when ld -shared slower than
dlltool %) .
Def/implib creation
-------------------
1. I noticed that dlltool --export-all marks symbols from assembly
code as data, even though some are code. Here, I am to be blamed:
patch to classify symbols in --export-all case was submitted by me.
However, it is two-lines-long: I just take "is_function" flag from bfd
structure for symbol. So, it seems that bfd sets that flag only for
symbols having their type set by .def assembly directive accordingly.
Workaround would be to delete DATA option from def manually.
2. Dlltool does not support symbol aliasing option (onename=othername
in def), allowing symbol imported from dll to be seen by application
with the other name. That's mostly advanced option, which may be
required for example to create dll proxying other dll. Available
workaround is to supply symbol from dll the DATA option, so the
application will get pointer to the symbol contents in dll as
_im__<symbol>. Also, patch to support aliasing feature wa sposted to
mingw32 maillist.
3. Last note about creation of correct defs from existing (binary-only)
dll. I've patched Anders Norlander's pexports program for that,
available from http://www.is.lg.ua/~paul/devel/binutils.html . It
should be noted that task to classify symbols from binary file by
code/data can be done only heuristically. I used one simple that
symbol contained in text segment is code, any other - data. There's
however one very important exception I always knew but failed to map
on my pexports hack: gcc stuffs const data into text segment.
Hopefully, not so much C code uses const global data, but it can
really lead to problems with C++. I'm going to improve heuristics by
examining contents of given symbol. The general rule however is to
produce def/implib from object files whenever possible.
Best regards,
Paul mailto:paul-ml AT is DOT lg DOT ua
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -