Martin,
I have just been able to get molmol to link using a libGLw.a
built from a copy of the original widgets-sgi sources (that I use
for linux builds of molmol rpms) and the hack you mention below.
While this completes the linkage, the resulting binary doesn't
render properly. It produces no errors but appears to startup in
X11 rather than OpenGL mode. The structures it renders appear as
solid lines and circles with no 3D depth. The resulting binary
shows...
otool -L /sw/share/molmol/src/main/molmol
/sw/share/molmol/src/main/molmol:
/sw/lib/libtiff.3.dylib (compatibility version 12.0.0, current version
12.2.0)
/sw/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version
63.0.0)
/sw/lib/libpng12.0.dylib (compatibility version 19.0.0, current version
19.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.3)
/usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
version 9.0.0)
/sw/lib/libXm.3.dylib (compatibility version 4.0.0, current version
4.2.0)
/usr/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current
version 9.0.0)
/usr/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current
version 7.0.0)
/usr/X11/lib/libXp.6.dylib (compatibility version 9.0.0, current
version 9.0.0)
/usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current
version 16.0.0)
/usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current
version 11.0.0)
/usr/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current
version 7.0.0)
/usr/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current
version 10.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
/usr/X11/lib/libGLU.1.dylib (compatibility version 1.3.0, current
version 1.3.0)
/usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current
version 1.2.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version
47.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
I believe we are pretty much stuck here with regards to libGLw until Xcode 3.0
is
fixed to allow for the cyclic linkages in the case of libGL. There is a reason
that
was done in the first place (due to the additional X11 custom code required in
libGL)
and Apple simply didn't realize this corner case had to be dealt with properly.
Your other suggestion of using /usr/X11/lib/libGL.dylib instead doesn't link.
It triggers the cyclic link error unless
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
is passed as well. In that case, you get the same result, a molmol program that
can link
but doesn't display in OpenGL but only X11.
Jack
ps I really think we need to push this issue by trying to make sure sites like
Macintouch and MacFixit expose it to the public. Only if Apple feels that the
media is bashing them for sloppy coding will they likely feel pressured to
address this in a timely manner.
pps If I try to link with Apple's libGLw.dylib using the same approach that
links with the locally built static libGLw, I get a single link error...
/usr/bin/gcc -o molmol -I../../tools/include -I../../sg/include -I../../include
-DMAXINT=INT_MAX -I/usr/X11R6/include -I/sw/include -bind_at_load -O
-bind_at_load MolMol.o MolInit.o ../../lib/libcip.a ../../lib/libcmd.a
../../lib/libui.a ../../lib/libgraph.a ../../lib/libio.a ../../lib/libpu.a
../../lib/libcalc.a ../../lib/libprim.a ../../lib/libdata.a ../../lib/libattr.a
../../lib/libfileio.a ../../lib/libos.a ../../sg/lib/libsg.a
../../tools/lib/libtools.a /sw/lib/libtiff.3.dylib /sw/lib/libjpeg.dylib
/sw/lib/libpng.dylib /usr/lib/libz.dylib -L/usr/lib -L/sw/lib -L/usr/X11R6/lib
-lX11 -lXm -lXmu -lXt -lXp -lXpm -lX11 -lXext -lSM -lICE -lm -lc -lGLU
/usr/X11R6/lib/libGL.dylib /usr/X11R6/lib/libGLw.dylib
/System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib -lmx
Undefined symbols:
"_GLwCreateMDrawingArea", referenced from:
_IOMotifOGLInit in libio.a(MotOGL.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
On Sun, Oct 28, 2007 at 10:36:52AM +0100, Martin Costabel wrote:
> 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
>
>
-------------------------------------------------------------------------
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
