Problems linking against OSG on OS X Tiger (on a Power PC)

[Ryan Schmidt]

On Dec 7, 2008, at 09:57, Severin Kacianka wrote:

> I hope I do not ask a too obvious question, but I am just trying to  
> get familiar with OSG and in the process want to be able to compile  
> it on Linux and OS X. On Linux I have no problems compiling a  
> sample program like this:
> g++ -I /usr/local/include/osg/ -losg -losgViewer -o foo test.cpp
>
> On OS X I installed OS X via macports. First I tried to compile it  
> directly form the sources, but ran into the bug described here:
> http://trac.macports.org/ticket/17294
>
> Compiling and installing via macports worked fine.
> However if I try to compile a sample program I get the following  
> error:
>
> g++  -L/opt/local/lib/ -I/opt/local/include/  -losg -losgViewer -o  
> foo test.cpp
> /usr/bin/ld: warning can't open dynamic library: libOpenThreads. 
> 11.dylib referenced from: /opt/local/lib//libosg.dylib (checking  
> for undefined symbols may be affected) (No such file or directory,  
> errno = 2)
> /usr/bin/ld: warning can't open dynamic library: libosgGA.48.dylib  
> referenced from: /opt/local/lib//libosgViewer.dylib (checking for  
> undefined symbols may be affected) (No such file or directory,  
> errno = 2)
> /usr/bin/ld: warning can't open dynamic library: libosgText. 
> 48.dylib referenced from: /opt/local/lib//libosgViewer.dylib  
> (checking for undefined symbols may be affected) (No such file or  
> directory, errno = 2)
> /usr/bin/ld: warning can't open dynamic library: libosgDB.48.dylib  
> referenced from: /opt/local/lib//libosgViewer.dylib (checking for  
> undefined symbols may be affected) (No such file or directory,  
> errno = 2)
> /usr/bin/ld: warning can't open dynamic library: libosgUtil. 
> 48.dylib referenced from: /opt/local/lib//libosgViewer.dylib  
> (checking for undefined symbols may be affected) (No such file or  
> directory, errno = 2)
> /usr/bin/ld: Undefined symbols:
> *snip long list of symbols*
> collect2: ld returned 1 exit status
>
> So for some reason ld cannot find the references from the libraries  
> among each other. The directory looks like this:
>
> libOpenThreads.11.dylib -> libOpenThreads.2.3.0.dylib
> libOpenThreads.2.3.0.dylib
> libOpenThreads.dylib -> libOpenThreads.11.dylib
>
>
> (other libs are linked in the same manner)
>
> So the libs are there, but somehow not referenced correctly. Does  
> anyone know what the problem may be, or any other way to use OSG on  
> OS X?

I see that it's linked this way:

$ otool -L /opt/local/lib/libosg.dylib
/opt/local/lib/libosg.dylib:
         libosg.48.dylib (compatibility version 48.0.0, current  
version 2.6.1)
         libOpenThreads.11.dylib (compatibility version 11.0.0,  
current version 2.3.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.3.10)
         /System/Library/Frameworks/AGL.framework/Versions/A/AGL  
(compatibility version 1.0.0, current version 1.0.0)
         /System/Library/Frameworks/OpenGL.framework/Versions/A/ 
OpenGL (compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,  
current version 7.4.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
current version 1.0.0)
$

That looks wrong. It should look like this:

$ otool -L /opt/local/lib/libosg.dylib
/opt/local/lib/libosg.dylib:
         /opt/local/lib/libosg.48.dylib (compatibility version  
48.0.0, current version 2.6.1)
         /opt/local/lib/libOpenThreads.11.dylib (compatibility  
version 11.0.0, current version 2.3.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.3.10)
         /System/Library/Frameworks/AGL.framework/Versions/A/AGL  
(compatibility version 1.0.0, current version 1.0.0)
         /System/Library/Frameworks/OpenGL.framework/Versions/A/ 
OpenGL (compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,  
current version 7.4.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
current version 1.0.0)
$

This probably means they're not using the -install_name parameter.