Jack Howarth wrote: > This is a corner case of the same problem with no possible workaround. > The problem is that libGL is a unique library in that it needs to exist > in a special X11 version with additional symbols. The libGLw library > uses some of these symbols unique to the X11 version of libGL.dylib and > thus the nasty hack of substituting the framework version of libGL.dylib > can't possibly provide the required symbols for libGLw.dylib. I have > filed a radar report 5563698 "X11R6's libGLw.dylib can not be linked under > Leopard" > on this issue.
I think there is some misunderstanding here. The "nasty hack" does not replace anything by anything else, quite the opposite: It tells ld to really do what it is asked to do and not to get smart and substitute one libGL.dylib for another one. The situation is the following (as you can see with otool -L): /usr/X11/lib/libGL.dylib is linked with the OpenGL.framework version of libGL.dylib. This has always been the case. What has changed in Leopard is that the linker is even less following Apple's own philosophy of install_names and more and more following the Linux (or GNU binutils) philosophy of library paths (they are probably hiring too many former Linux or Windows programmers :-( ). This causes problems when two different libraries have the same name. It has been a problem at runtime before where dylib found /sw/lib/libjpeg.dylib instead of the framework version of libJPEG.dylib. Now it is ld that is suffering from the same disease. It is even mentioned in man ld now, under "Indirect dynamic libraries": "Even though indirect dylibs are specified via a full path, ld first uses the specified search paths to locate each indirect dylib. If one cannot be found using the search paths, the full path is used." This is pure madness, and Apple should be told so at every occasion (Not that it will matter to them, as witnessed by the equally crazy /usr/lib/libreadline.dylib which is still present in Leopard). In the case of -L/usr/X11/lib -lGL, this new behavior of ld means that instead of the indirectly referenced OpenGL.framework libGL.dylib, ld stupidly tries to load /usr/X11/lib/libGL.dylib a second time and then sees this as a circular reference (which in reality is not there). The "nasty hack" circumvents this new behavior of ld. What would also work, I think, is to place the framework dylib explicity on the linker path, so that it is not counted as an indirect dylib: -L/usr/X11/lib -lGL /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib Or perhaps even simply put /usr/X11/lib/libGL.dylib there. But I am not sure if this has other side effects. > I am extremely disturbed by the utter ineptitude at Apple that let this > fundamental breakage occur. Waiting until the very last second to build > a major component of Leopard (X11) with the new linker is imbecilic at > best (and a dereliction of duties at worst). At the release of every new version of OSX, Apple have been doing similar things. They always introduced some major last-minute breakage in the developer tools. -- 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 Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
