This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [avail for test] libtool-devel-20030121-1


Ralf Habacker wrote:

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: [1] Which is the mostly stable identifier we build on ?
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.

Now, the relative *offset* of that symbol might move around. But the symname is not likely to change.


This sounds good.
Great, because it's already implemented, posted to libtool-patches, and accepted into CVS.

I have no problem with this.
great. There will be a new test release of libtool posted as soon as I can get it uploaded.

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.

--Chuck


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]