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

[Ryan Schmidt]

On Dec 7, 2008, at 15:39, Ryan Schmidt wrote:

> 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.

I filed a ticket:

http://trac.macports.org/ticket/17577