[OS X / Code::Blocks] Dynamic libarary Pfad und boost Linker-Problem

[badday]

Moin zusammen,

ich bin gerade dabei, ein Projekt auf OS X zu portieren, habe aber noch ein paar Probleme.

1. Dynamic Library Pfad
Unter Linux war ich immer gewohnt, etwa ../bin als relativen Pfad anzugeben, da da immer vom Verzeichnis, in dem das binary ausgeführt wird, ausgegangen zu werden scheint. Unter OS X gebe ich nun momentan immer
DYLD_LIBRARY_PATH=<full path to binary directory>
vor der Ausführung an. Kann ich dies irgendwie umgehen, indem ich das als Linker-Flag o. Ä. angebe? Ich verwende die gcc.


2. Boost Linking Problem
Ich habe die libs und Abhängigkeiten von macports.org ( http://www.macports.org ). Die Bibliotheken wurden erfolgreich kompiliert und ich linke sie in Code::Blocks wie üblich durch einen Eintrag unter "Link libraries".
Allerdings meldet er dennoch am Ende beim Linken:

Undefined symbols:

"boost::system::get_generic_category()" referenced from:
__static_initialization_and_destruction_0(int, int) in myfile.o
__static_initialization_and_destruction_0(int, int) in myfile.o
__static_initialization_and_destruction_0(int, int) in myfile.o
"boost::system::get_system_category()" referenced from:
__static_initialization_and_destruction_0(int, int) in myfile.o
__static_initialization_and_destruction_0(int, int) in myfile.o

ld: symbol(s) not found

Mach ich hier irgendetwas falsch?



Vielen Dank & Gruß,

badday

 

[deepthroat]

Hi.

zu 1) Man kann den Pfad zu Bibliotheken im Binary hard-kodieren. Als Optionen für den Linker eintragen: -Wl,-rpath,PFAD_ZU_LIBS

zu 2) Wie sieht die vollständige Kommandozeile aus? Verwendest du statische oder dyn. Bibliotheken?

Gruß

 

[badday]

zu 2) Wie sieht die vollständige Kommandozeile aus? Verwendest du statische oder dyn. Bibliotheken?

Ich verwende statische Bibliotheken bei boost. Kommandozeile:

g++ -L../../../Developer/SDKs/MacOSX10.6.sdk/usr/X11/lib  -o ../bin/exec .objs/file1.o .objs/file2.o .objs/file3.o   -framework OpenGL -framework IOKit -framework Carbon -framework Cocoa -framework Quartz -framework OpenAL  ../Abhaengigkeiten/boost/lib/libboost_system.a ../Abhaengigkeiten/boost/lib/libboost_filesystem.a [more static libs] [dynamic libs] -lX11 -lXxf86vm -lGL -lpthread -lcurl -lz

(Ich habe das ganze der Übersichtlichkeit halber etwas verkürzt und führe daher nicht alle libs auf).


Danke & Gruß,

badday

 

[badday]

Problem lag darin, dass ich noch ältere Header benutzte, als die Lib-Version war. Hat sich mit einen update erledigt. Vielen Dank dennoch an deepthroat.

 

[badday]

Das Problem 1) mit den dynamischen libs besteht leider weiterhin, wie ich gerade feststellen musste. Ich gebe die dyn. libs etwa so an:

../bin/lib.dynlib

Als Linkeroption des weiteren:

Wl,-rpath,../bin

Er beschwert sich aber sowohl mit, als auch one Linkeroption, dass er ../../bin/lib.dynlib nicht finden könnte. Warum sieht er sich dazu veranlasst, nochmal ein "../" beim Pfad davorzustellen?

 

[badday]

Ein weiteres Problem ist, dass er unterschiedliche working directories hat bei der executable und den dyn. libs. getwd() liefert aus der executable korrekt <somepath>/bin zurück, aus der dyn. lib dagegen <somepath>. Wie wird das working directory der dyn. lib determiniert und wie kann ich darauf Einfluss nehmen?
Den Pfad <somepath> gibt getwd() offenbar selbst aus einer statisch gelinkten lib zurück.

Hängt das vll. mit dem obigen Problem zusammen?

EDIT: Habe gerade folgendes festgestellt: Er versucht offenbar die libs unter dem Pfad zu laden, unter dem sie in "Output filename" angegeben sind. Das macht aber für mich so keinen Sinn, ist das doch der relative Pfad ausgehend von dem dir, indem sich die Projektdateien der dyn. lib zu befinden scheinen. Muss zugeben, nicht ganz zu verstehen, wie OS X die dyn. libs lädt, bzw. wie hier die working dirs der libs zu stande kommen...