G++ static libary angeben - wie?



  • Hallo Leute,

    ich habe mit Cmake Libarys der Grafiklib SFML erstellt und diese in die Standardumgebung unter Linux installiert.

    Leider kenne ich mich nicht so sehr mit dem G++ Compiler aus.
    Ich kann meine Testanwendung compilieren in dem ich folgende Befehle absetze:

    g++ -c test.cpp
    g++ test.o -o sfml-app -lsfml-graphics -lsfml-window -lsfml-system
    

    starten kann ich dann einfach per doppelclick oder ./sfml-app. Das Problem das ich habe, andere können es eben auf ihrem System nicht. Liegt mit sicherheit daran, dass die sfml nicht installiert haben. D.h mit den Befehlen oben werden die shared libarys benutzt und nicht die static libarys. Die Frage die ich mir jetzt stelle, wie muss ich den Befehl oben abändern um bspw. mit meiner static-release libary zu linken? Diese haben folgende Namen:

    libsfml-graphics-s.a
    
        libsfml-window-s.a
    
        libsfml-system-s.a
    

    Ich würde mich über Hilfe und Aufklärung sehr freuen.

    Lg


  • Mod

    Mit -static als Schalter. Sollten die Bibliotheken tatsächlich andere Namen haben (also das "-s" am Ende), dann musst du natürlich auch entsprechend die Namen beim Linkkommando ändern.

    Allgemein ist es hoch ungewöhnlich in Linux, statisch gelinkte Software zu verteilen. Verteil den Quellcode mit Buildscript. Wenn du unbedingt Binaries verteilen musst, dann verteil sie in einem der Formate der bekannten Paketmanager (oder auch in allen). Die kümmern sich dann um die Abhängigkeiten.



  • Hallo SeppJ,

    danke für deine Antwort. Leider hilft mir die noch nicht ganz weiter. Ich will die Sachen nur fertig gelinkt verteilen damit Freunde mein Spiel mal schnell testen können.

    Hier mal ein paar Eingaben die ich probiert habe und deren Fehlerausgabe

    g++ test.o -o sfml-app -static -lsfml-graphics -lsfml-window -lsfml-system
    
    /usr/bin/ld: cannot find -lsfml-graphics
    /usr/bin/ld: cannot find -lsfml-window
    /usr/bin/ld: cannot find -lsfml-system
    
    g++ test.o -o sfml-app -static  libsfml-graphics-s.a libsfml-window-s.a libsfml-system-s.a
    
    g++: Fehler: libsfml-graphics-s.a: Datei oder Verzeichnis nicht gefunden
    g++: Fehler: libsfml-window-s.a: Datei oder Verzeichnis nicht gefunden
    g++: Fehler: libsfml-system-s.a: Datei oder Verzeichnis nicht gefunden
    
    g++ test.o -o sfml-app libsfml-graphics-s.a libsfml-window-s.a libsfml-system-s.a
    
    g++: Fehler: libsfml-graphics-s.a: Datei oder Verzeichnis nicht gefunden
    g++: Fehler: libsfml-window-s.a: Datei oder Verzeichnis nicht gefunden
    g++: Fehler: libsfml-system-s.a: Datei oder Verzeichnis nicht gefunden
    

    Irgendwie geht das alles nicht. Die Dateien existieren aber:

    /usr/local/lib$ ls
    
    libsfml-audio-d.so         libsfml-graphics.so.2.0   libsfml-system.so.2
    libsfml-audio-d.so.2       libsfml-network-d.so      libsfml-system.so.2.0
    libsfml-audio-d.so.2.0     libsfml-network-d.so.2    libsfml-window-d.so
    libsfml-audio-s.a          libsfml-network-d.so.2.0  libsfml-window-d.so.2
    libsfml-audio-s-d.a        libsfml-network-s.a       libsfml-window-d.so.2.0
    libsfml-audio.so           libsfml-network-s-d.a     libsfml-window-s.a
    libsfml-audio.so.2         libsfml-network.so        libsfml-window-s-d.a
    libsfml-audio.so.2.0       libsfml-network.so.2      libsfml-window.so
    libsfml-graphics-d.so      libsfml-network.so.2.0    libsfml-window.so.2
    libsfml-graphics-d.so.2    libsfml-system-d.so       libsfml-window.so.2.0
    libsfml-graphics-d.so.2.0  libsfml-system-d.so.2     pkgconfig
    libsfml-graphics-s.a       libsfml-system-d.so.2.0   python2.7
    libsfml-graphics-s-d.a     libsfml-system-s.a        python3.3
    libsfml-graphics.so        libsfml-system-s-d.a
    libsfml-graphics.so.2      libsfml-system.so
    

    Woran liegt das?

    Liebe Grüße

    🙂



  • Was ich noch fragen wollten, du hast den Paketmanager erwähnt der sich um die Abhängigkeiten kümmert wenn ich es als binary verteilen will.

    Gibt es dafür irgendwelche einführende Literatur wie soetwas alles funktioniert? Würde mich doch mal interessieren.


  • Mod

    g++ test.o -o -static sfml-app-s -lsfml-graphics-s -lsfml-window-s -lsfml-system-s
    

    Meme321 schrieb:

    Was ich noch fragen wollten, du hast den Paketmanager erwähnt der sich um die Abhängigkeiten kümmert wenn ich es als binary verteilen will.

    Gibt es dafür irgendwelche einführende Literatur wie soetwas alles funktioniert? Würde mich doch mal interessieren.

    Die Anleitungen der Distributionen zum Verteilen von Software?



  • Vielen Dank für deine Gedult.

    Ich werde wohl noch viel, sehr viel lesen müssen. Schwierig den Überblick zu kriegen 🙂 !



  • Zur Erklärung: -l ist die Linkeroption und dahinter gibt man den Namen der Library (aber ohne den "lib"-Präfix sowie den ".so" oder ".a" Suffix an).



  • Meme321 schrieb:

    Gibt es dafür irgendwelche einführende Literatur wie soetwas alles funktioniert? Würde mich doch mal interessieren.

    Für RPM (Fedora, Redhat, OpenSuse) gibt es im Fedora-Wiki eine Anleitung.

    http://fedoraproject.org/wiki/How_to_create_an_RPM_package

    Lass dich vom Umfang nicht abschrecken, das ganze ist halb so schwer wie es vielleicht auf den ersten Blick aussieht. Grundsätzlich läuft das ganze so ab, dass du eine Textdatei (im RPM-Jargon Specfile genannt) erstellst, die beschreibt wie das Paket aus dem vorhandenen Quellcode gebaut werden soll.

    Das RPM-Buildsystem entpackt deinen Quellcode und ruft dein Makefile oder deine Buildskripte so auf, wie du es im Specfile beschrieben hast. Für gängige Buildsysteme (Autotools, cmake, whatever) gibt es Makros, die dir ein bisschen Arbeit abnehmen.

    Anschließend wird das jeweilige Äquivalent zu "make install" aufgerufen, allerdings mit einem bestimmten, temporären Zielverzeichnis (Buildroot genannt). In der %files-Sektion deines Specfiles gibst du an, welche Dateien/Pfade des Buildroots letztendlich im Paket landen sollen.

    Das war es auch eigentlich schon. Während des Vorgangs gibt es einige Möglichkeiten das Ergebnis zu beeinflussen. Du kannst etwa das Anwenden von Patches auf den Sourcecode festlegen oder bestimmen, dass bei der Installation und Deinstallation des Pakets bestimmte Skripte ausgeführt werden sollen und so weiter. Für den Anfang würd ichs erstmal mit einem minimalen Paket versuchen.

    Diese Prinzipien sind eigentlich in allen Distributionen gleich. In den Details gibt es natürlich mehr oder weniger große Unterschiede.


Log in to reply