I have:
[ufo-2:~] sparker% ls -lisa /usr/X11R6/lib/libGL.dylib
3472812 8 lrwxr-xr-x 1 root wheel 13 Oct 30 00:09 /usr/X11R6/lib/ libGL.dylib@ -> libGL.1.dylib
[ufo-2:~] sparker% ls -lisa /usr/X11R6/lib/libGL.1.dylib
3472811 4672 -rwxr-xr-x 1 root wheel 2390576 Sep 23 23:21 /usr/ X11R6/lib/libGL.1.dylib*
You might try reinstalling xcode 3, but I suspect that won't help. You can try finding the X11 package on the install disks and reinstalling.
Steve
On Jan 5, 2008, at 7:57 PM, Solomon Boulos wrote:
Did you upgrade from Tiger to Leopard or was this a fresh leopard install?
zeppelin:/usr/X11R6/lib boulos$ ls -lisa libGL.dylib
569674 8 lrwxr-xr-x 1 root wheel 13 Nov 2 20:23 libGL.dylib@ -> libGL.1.dylib
On Jan 5, 2008, at 6:54 PM, Ingo Wald wrote:
Hmmmm.
The file is there, and it's not empty
ingo-walds-computer:gcc ingowald$ nm /usr/X11R6/lib/libGL.dylib | grep _glX
ingo-walds-computer:gcc ingowald$ ls -lisa /usr/X11R6/lib/ libGL.dylib
2818104 8 lrwxr-xr-x 1 root wheel 65 Nov 22 01:43 /usr/X11R6/ lib/libGL.dylib -> /System/Library/Frameworks/OpenGL.framework/ Libraries/libGL.dylib
ingo-walds-computer:gcc ingowald$ ls -lisa /System/Library/ Frameworks/OpenGL.framework/Libraries/libGL.dylib
1704507 1144 -rwxr-xr-x 1 root wheel 584848 Oct 2 19:48 / System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib
ingo-walds-computer:gcc ingowald$
'nm' shows lots of terminal symbols for "_glSomthing", but in fact not a single one that contains glX something....
When I disable that single line that uses this call, then I get stuck in other link problems with libmagick, but that may be due to outdated macports; I just started updating them. But I have no idea how to fix that libGL thing...
Cheers,
Ingo
Steven G. Parker wrote:
Something is fishy with your opengl. _glXUseXFont should be in /usr/X11R6/lib/libGL.dylib:
[ufo-2:~] sparker% nm /usr/X11R6/lib/libGL.dylib | grep _glXUseXFont
00030c84 T _DRI_glXUseXFont
00021393 T _glXUseXFont
What do you get? is this a 64 bit build or a 32-bit build?
Steve
On Jan 5, 2008, at 7:39 PM, Ingo Wald wrote:
From: Ingo Wald <ingowald@gmail.com>
Date: January 5, 2008 7:39:18 PM MST
To: Solomon Boulos <boulos@cs.utah.edu>
Subject: Re: [Manta] still compile problems
just tested.
It "seems" to have fixed the compile issue. The reason I say "seems" is that I still cannot comile the whole project through, but it now exits with the same linking issue as with gcc
Linking CXX shared library ../lib/libManta_Core_XUtils.dylib
cd /Users/ingowald/Projects/manta/icc/Core && /opt/local/bin/ cmake -P CMakeFiles/Manta_Core_XUtils.dir/cmake_clean_target.cmake
cd /Users/ingowald/Projects/manta/icc/Core && /opt/local/bin/ cmake -E cmake_link_script CMakeFiles/Manta_Core_XUtils.dir/ link.txt --verbose=1
/usr/bin/icpc -Wall -O3 -DNDEBUG -g -restrict -dynamiclib -headerpad_max_install_names -Wl,-dylib_file,/System/Library/ Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/ System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib -o ../lib/libManta_Core_XUtils.dylib -install_name / Users/ingowald/Projects/manta/icc/lib/libManta_Core_XUtils.dylib "CMakeFiles/Manta_Core_XUtils.dir/XUtils/XHelper.o" -L/Users/ ingowald/Projects/manta/icc/lib -L/usr/X11R6/lib -lManta_Core - lGLU -lGL -lSM -lICE -lX11 -lXext -lxml2 -lpthread
xilibtool: executing 'libtool'
Undefined symbols:
"_glXUseXFont", referenced from:
__ZN5Manta7XHelper9getGLFontEP11XFontStruct in XHelper.o
ld: symbol(s) not found
libtool: internal link edit command failed
make[2]: *** [lib/libManta_Core_XUtils.dylib] Error 1
make[1]: *** [Core/CMakeFiles/Manta_Core_XUtils.dir/all] Error 2
make: *** [all] Error 2
I guess that means it got past the original error...
Anybody has any idea what could cause this link error ? I'm pretty sure I updated xcode to the leopard version...
Cheers,
Ingo
Solomon Boulos wrote:
This should now be fixed. Could someone on ICC Leopard test this? (and someone still on Tiger make sure I didn't screw anything up...)
On Jan 5, 2008, at 12:53 AM, Solomon Boulos wrote:
The solution is very simple: we need a APPLE_LEOPARD #define through CMake. I haven't had the time to look at James's CMake version macros to determine how to make the following very simple test (which is the only stable way to test for Leopard...):
uname -r on Leopard returns a major version of 9 while Tiger is 8. Checking for major version >= 9 and defining APPLE_LEOPARD will allow us to check for Leopard regardless of compiler predefined macros. The code James wrote for version stuff is in CMake/Macros.cmake but again, that's all I know and I haven't looked into this (yes it would only take maybe 20 minutes or so to do).
Solomon
PS - My laptop has neither leopard nor 64-bits support nor ICC ;)
On Jan 4, 2008, at 10:28 PM, Ingo Wald wrote:
hi all,
some time ago I reported some compile problems with manta under leopard, some sigaction whatever problem.
back then somebody (abe ? solomon?) said there was a soluion, but it wasn't checked in yet. however, after I finally have some time for coding again I just updated the codebase, but still run into the same error.
could anybody please commit the fix for that ? i know you all use leopard and 64-bit macbooks, and at least a few will probably use the intel compiler ... so there _must_ be a solution, I guess....
Cheers,
Ingo
Archive powered by MHonArc 2.6.16.