This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Ralf Habacker <Ralf dot Habacker at freenet dot de>
- Cc: cygwin <cygwin at cygwin dot com>
- Date: Mon, 17 Feb 2003 20:39:35 -0500
- Subject: Re: [avail for test] libtool-devel-20030121-1
- References: <001e01c2d6d6$dc051060$c66307d5@BRAMSCHE>
Ralf Habacker wrote:
filenames change because evil twisted pesky end-users change them, at
any time, for any reason. The _dll_iname symbol has been in every
DLL/implib I've built in the four (five?) years I've been using cygwin.
The only way that symbol is going to change is if somebody
deliberately changes that particular piece of binutils.
the negative: Ralf, you keep trying to assume things based on filenames.
Filenames LIE. Whether it is the name of the archive (foo.dll.a) or
the name of an object in the archive (dxxxxxx.o), it's gonna fail -- and
it will fail in EXTREMELY hard-to-track-down ways.
You may be right in this issue, but couldn't the symbol "_dll_iname" doesn't
change in future implementation too ? The important question seems to me like
this:  Which is the mostly stable identifier we build on ?
Now, the relative *offset* of that symbol might move around. But the
symname is not likely to change.
Great, because it's already implemented, posted to libtool-patches, and
accepted into CVS.
This sounds good.
great. There will be a new test release of libtool posted as soon as I
can get it uploaded.
I have no problem with this.
It'll work faster than the current -test release without any user
changes -- and you should be able to see an additional speedup on your
system, if you've got your hacked file magic ready to go.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html