qtforum.de

Hallo Alle,

wenn man mit Qt-Creator eine dynamische Bibliothek entwickelt,
dann installiert der Creator diese in '/usr/lib'.
[code]
sudo make install
dir /usr/lib | grep libfoo.dylib
lrwxr-xr-x 1 root wheel 20 24 Aug 17:37 libfoo.dylib -> libfoo.1.0.0.dylib
[/code]
Dabei werden die Headerdateien 'foo.h und foo_global.h' nicht kopiert.
Ich habe das 'Makefile' geändert und die beiden Datein händisch kopiert.
Das Dumme ist, auf beide Dateien ( weil mit 'sudo' kopiert ) kann ich dann beim erneuten
Kompilieren nicht zugreifen.
Ich muss also nach dem Installieren noch ein 'chown' auf beide Datein anwenden.
Das ist eigentlich ganz schön umständlich!

Nun meine Fragen an die Comunity:

1. Kopiert man seine eigenen Bibliothken nicht besser nach 'usr/local/lib'?
2. Wie macht man sie dann dem Loader bekannt?

GBunge

Header - Dateien haben normalerweise 644 als Zugriffsattribute - demnach sollte man danach die Dateien auch als normaler Nutzer lesen können.
Zum automatischen Installieren braucht man ein extra target: Siehe auch qmake-Doku

Hallo Christian81,
danke für die schnelle Reaktion!

Daraus habe ich gelernt, dass man nicht den Besitzer der Headerdateien ändern muss sondern nur die
Zugriffsrechte. OK

Allerdings habe ich noch zwei grundsätzliche Fragen.
1. Warum wird die Bibliothek nach '/usr/lib' kopiert?
2. Ist es nicht besser eigene Bibliotheken in '/usr/local/lib' zu halten?

Zu Deinen Hinweisen ebenfalls eine Frage.
1. Wie teile ich 'qmake' im foo.pro das mit, damit diese drei Statements auch in das Makefile gelangen?

Gruss GBunge

Warum qmake /usr anstatt /usr/local benutzt weiß ich nicht - benutze qmake nicht.
Zu den Befehlen - die hgehören natürlich in der pro-File, siehe auch http://qt-project.org/doc/qt-4.8/qmake-reference.html

Generell solltest du deinen Entwicklungsprozess umstrukturieren

Zum entwickeln und testen solltest du auch unter linux eigene shared libs lokal lassen, und nicht global kopieren ... Dann kannst auch beim kompilieren die .so ueberschreiben etc.
Du kannst sowas machen in dem deine (Test) app ueber nen script startest und die .so vorher einbindest (LD_PATH)

erst beim deployen (make install) sollte das Ding ins "richtige" systemverzeichniss kopiert werden und versioniert (symbolische links fuer die s.o) .... dann entwickelst und testest aber nicht mehr die App sondern maximal die Installation
binary: /usr/bin - shared lib:/usr/lib
vs.
binary: /usr/local/bin - shared lib:/usr/local/lib

das usr/local ist Normal für distrie unabhaengige dinge, waehrend alles was die distrie installiert, direct unter /usr kommt.
Technisch isses solange egal, wie keinen namenskonflikt hasst. /usr/bin und /usr/local/bin sind im suchpfad ; /usr/lib und /usr/local/lib sind im LD_PATH ...
Sauber ist es, die teile in /usr/local zu pflegen, und erst die Distrie verantwortlichen ziehen die nach /usr hoch, wenn das Programm mal von ner Distrie aquiriert wird

Alternativ wird auch oft verwendet, wenn es auch für OS ist, die nicht den FHS unterstüzen ...
alles ins /opt/${ProgramName} und ins /usr/bin nur nen script, was den LD_PATH setzt und in /opt/${ProgramName} das binary aufruft ...

von qmake hab ich weniger ahnung, eher mit cmake ... dort sind aber build, test und deploy unterschiedliche schritte ... ich denk bei qmake sollt es aehnlich sein.

Ciao ...