[avail for test] readline-4.2-1
Sun Jun 10 17:35:00 GMT 2001
----- Original Message -----
From: "Charles S. Wilson" <email@example.com>
To: "Jason Tishler" <Jason.Tishler@dothill.com>; "Cygwin Users"
Sent: Monday, June 11, 2001 10:03 AM
Subject: Re: [avail for test] readline-4.2-1
> If you've been following the subthread between Robert Collins and I,
> then you understand why I haven't pushed too hard to get the readline
> patch into Chet's official sources. I really don't want to fight that
> battle -- and then have to fight to get it removed if Paul
> modified binutils works as advertised.
> So, I guess we'll just have to live with the status quo for a the time
> being, unless you want to take over readline, 200k patch and all.
I've been quite for for a bit, but have been digging deep into libtool,
to understand what options are arriving.
This may be of interest to folk here who aren't on the libtool list, so
I'm going to give a quick summary: for detail see the libtool list
libtool for cygwin today:
* uses dllwrap and ~5 steps of linking.
* cannot build both a static and shared library if it depends on other
libraries. (Doesn't understand the concept of decorated headers, so
cannot pass per-destination-mode per-depended library defines.)
The first point is easy enough to resolve, if we are willing to let B19
folk sit out in the cold :]. The second point is _much_ harder, and a
matter of a certain amount of dispute of approach. It's actually a
special case of a harder problem related to passing defines needed when
compiling code that will link with a given library.
Paul's --auto-import switch:
This is a really clever hack. It actually breaks the PE spec in a teensy
little way, but to date, no MS runtime linker appears to have an issue
with that.. (Read his description for more detail).
I have a modified libtool here that uses gcc -shared and the modified ld
to build both shared and static libraries, with dependencies, with no
decoration. And it works beautifully. It works with existing headers
that are decorated, because the auto-import only takes effect when a
"symbol not found" would have occured previously.
There seems to be a problem with dll's dependent on dll's built with
this ld, and Paul and I are discussing this now on libtool/binutils. (At
testcase is available at
If anyone is interested I'm happy to provide my custom libtool for
experimentation (I haven't tarred it up yet, so just let me know). I
have discussed the approach I'm taking with the libtool maintainers, so
there shouldn't be any major issue with getting it merged back in, IFF
the community thinks there's no problem with the patched ld. As far as I
know I'm the first in-depth reviewer of the the patched ld, and I am not
a PE or binutils expert :].
All I'm doing at the point is dreaming up testcases that might cause
problems (starting with the full libtool test suite) and seeing if the
patched ld is better than the standard ld, or if a regression occurs.
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin