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: [1] 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.
--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/