Peter O'Gorman wrote:
[]
> I was simply going to ignore the rest of your comments about X11, ld
> and so forth, but I find that I can not do so.
I agree with you, Peter, that it is not a good idea to insult Ben Byer.
Over the past few days, he has been doing an incredible job of fixing a
good part of the remaining usability bugs of X11 on Leopard. It
certainly helped that there was and is a very friendly atmosphere on the
X11-users mailing list and his work is fully appreciated there.
OTOH, I have used some harsh words myself out of frustration with bugs
that I perceived as coming not from accidentally faulty behavior of some
tools, but from stupidity, both built-in stupidity of the tools and not
very smart decisions of their programmers.
The ld re-export cycle bug is such a case. Throwing away a perfectly
valid complete library path name and looking for the library elsewhere
instead is a behavior I cannot qualify as other than stupid. It may be
mandated by the structure of the library search code, but it is
objectively stupid all the same; the results prove it.
Among the not-so smart decisions is the one to use primitive names like
libGL.dylib, libPng.dylib etc for system libraries. They could at least
have used different install_names like libGL_system.dylib and then made
libGL.dylib a symlink pointing to the real file. (But then this whole
symlink-between-dylibs business always seemed to be above the head of
some of the OSX system programmers; just look at the absurd symlinks in
/usr/lib for libchars, libcurl, libedit, libiconv, libltdl and so on,
not to mention libreadline.) Oh, and I am just now noticing that all the
symlinks between the lib*.*.dylibs in /usr/X11/lib are backwards again,
like they were in the first X11 release in 2003.
[]
> As for the "new linker" that you keep complaining about. This is,
> essentially, the same linker that appears in tiger as ld64. It is the
> same linker as has always been used when building X11 on leopard, for
> all the seeds. The change in libGL linking was done, I am informed,
> due to a radar about GL performance. Prior to this radar report, X11's
> GL was the software only Mesa renderer. So, the change was not in the
> linker, but in X11.
From my observations, I cannot agree with your analysis. Of course, I
cannot test the Tiger ld64 on Leopard to see how it behaves, because it
does not run (BTW, the "ld_classic" that comes with Leopard is not
functional either, because it does not understand the binary format of
the new libSystem.dylib; but at least it finds the framework libGL.dylib
when looking for it as indirect dylib.)
But I ran the new ld with the old X11 from Tiger, and it crashes in the
same way, because the X11 libGL was linked with the framework libGL
there, too. On Tiger, ld64 does not suffere from the re-export cycle
crash. This "throw away the install_name path and look in the library
search path instead" behavior seems to be rather recent; according to
the ChangeLog in the ld sources, from around March-June 2007. And the
ChangeLog has even an entry from 2007-06-27:
<rdar://problem/5277857> OpenGL.framework and X11 both have a
libGL.dylib which can cause ld to segfault if both are found
So the problem was seen, the segfault was changed into into a more
gracious failure, but the problem was left unsolved.
This is definitely not the fault of X11.
--
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
