Ich kann eine ausführbare Datei mit gcc mit statischem Link bauen:Möglich, eine gemeinsam genutzte Bibliothek mit statisch verknüpfter Bibliothek zu erstellen?
gcc -static xxx.c -o xxx
So kann ich xxx ohne externe abhängige Bibliothek ausgeführt werden.
Aber was, wenn ich Shared Library ohne externe Bibliothek erstellen möchte? was ich meine ich will die gemeinsam genutzte Bibliothek statisch in seiner externel Referenz verknüpft
Diese Arbeit wird.
# Generate position independent code (PIC)
gcc -fPIC -c -o xxx.o xxx.c
# Build a shared object and link with static libraries
ld -shared -static -o xxx.so xxx.o
# Same thing but with static libc
ld -shared -static -o xxx.so xxx.o -lc
eine Klarstellung: die -static Flagge, auf gcc gegeben, wenn, wird an den Linker übergeben (ld) und teilt ihr mit, dass sie mit der statischen Version (.a) einer Bibliothek (die mit dem Flag -l angegeben ist) und nicht mit der dynamischen Version (.so) arbeiten soll.
Eine andere Sache: Auf meinem System (Debian) gibt das letzte Beispiel eine libc.a ... mit -fPIC Fehler neu kompilieren. Ziemlich sicher, das bedeutet, dass die libc.a, die ich auf meinem System habe, nicht mit -fPIC kompiliert wurde. Ein apt-cache Suche libc Bild gab jedoch einige Ergebnisse.
Siehe auch: Program Library HOWTO, SO: combining .so libs, ld(1), gcc(1)
Wenn Sie irgendwelche Pläne auf Portabilität für Ihre gemeinsame Bibliothek haben, libtool(1) verwenden. Es behandelt die meisten Details der Compiler-Flags für Sie und wird Ihr Leben unendlich erleichtern. Wenn Sie nicht libtool verwenden, aber später entscheiden, dass Sie Ihr Programm auf OS X oder Windows portieren wollen, werden Sie es am Ende neu erfinden.
@Chris Lutz, Build-unabhängige Bibliothek kann für Close-Source oder einfacher für den Kunden verwendet werden. –
@arsane: libtool (1) ermöglicht es Ihnen, Bibliotheken plattformunabhängiger zu erstellen. Es führt die entsprechenden Befehle aus, um eine (statische oder geteilte) Bibliothek für die Plattform zu erstellen, auf der es ausgeführt wird; Gute Sache, auch wenn du es nicht brauchst. – Inshallah
@arsane - Im Allgemeinen erfordern GNU-Tools nicht, dass Sie Ihren Code unter GNU-Lizenzen lizenzieren, um sie zu verwenden. Sie können legalen Code mit GCC kompilieren und trotzdem die Vorteile der GCC-Portabilität in Ihrem geschlossenen Quellcode nutzen, also können Sie libtool verwenden, um eine gemeinsame Bibliothek zu kompilieren, ohne Ihre Bibliothek GPL zu erstellen. Ich bin kein Anwalt oder Experte, so siehe die entsprechende Lizenz, aber im Allgemeinen tut GNU das nicht. –
Es gibt einige nette hackery Sie mit rpath tun können, so dass eine ELF ausführbare Datei oder .so wird im selben Verzeichnis wie sich .so-Dateien für seine abhängigen ersten Blick:
ein kurzes Skript machen Echo- rpath bestehend aus
echo '-Wl, - rpath = $ ORIGIN'
dass gcc Buildbefehlszeile hinzufügen -o Datei -lwhatever `echo-rpath ` Objekte
(Das Echo Mechanismus verhindert, dass das $ -Zeichen Stellen oder die Schale vom Essen und sichert sie in ld übergeben wird.)
@Inshalla, ich denke, das Problem ist, dass wir zwei mögliche .so zu einer verknüpfen . Bisher habe ich es versucht und gescheitert. –
Bitte beachten Sie den Link "SO: Kombination .so libs" 'in meiner Antwort. Es scheint keine einfache Möglichkeit zu geben, dynamische Bibliotheken zu kombinieren, wenn sie nicht mit dem Flag '--relocatable' verknüpft wurden (siehe Manpage ld (1)). – Inshallah
@Inshallah - Wenn Sie Nicht-PIC-Code in ein gemeinsames Objekt einbinden möchten, können Sie die gcc-Flags "-mimpure-text" verwenden. Nicht-PIC-Code in gemeinsam genutzten Objekten funktioniert gut, hat aber einige Nachteile (Codepages können nicht zwischen Prozessen aufgeteilt werden und erfordern Swap-Speicher, Relokationen verlangsamen das Laden des gemeinsam genutzten Objekts, können jedoch zur Laufzeit etwas schneller sein, da PIC-Code ~ ist 5% langsamer). –