So geben Sie einen alternativen Linker-Befehl an, wenn Sie mit „cc“ verknüpfen

Wenn Sie verwenden cc(1) Um ein Programm zu verknüpfen, wird ein Standard-Linker-Befehl aufgerufen. Beispielsweise könnte Ihre Version des Compilers so erstellt worden sein, dass sie standardmäßig /usr/bin/ld auf einer Unix-ähnlichen Plattform verwendet.

Gibt es eine Möglichkeit, einen anderen Linker-Befehl anzugeben? cc(1) (oder c++(1)) sollte verwenden (z. B. /usr/local/bin/ld anstatt /usr/bin/ld)? Ich interessiere mich hauptsächlich für GCC und Clang.

Ich suche nicht nach Methoden, bei denen die verschiedenen Kompilierungsschritte separat ausgeführt werden (z. B. Vorverarbeitung, Kompilierung, Assemblierung, Verknüpfung).

Ich hatte zum Beispiel gehofft, dass so etwas funktionieren könnte:

env LD=/usr/local/bin/ld cc foo.c -o foo

Aber das funktioniert nicht für gcc oder clang. Es würde natürlich funktionieren, wenn Sie ein Makefile hätten, das zuerst eine Objektdatei erstellt und dann ${LD} zum Verknüpfen aufruft (z. B. env LD=/usr/local/bin/ld make)

Aktualisieren (mit einer möglichen Motivation): Zum einfachen Testen mit einem anderen Linker als dem Standardlinker. Es wäre zum Beispiel schön, dies tun zu können:

cc --linker=/usr/local/bin/ld foo.c -o foo

Stattdessen müssen Sie die Objektdatei generieren und ausführen cc -v um die Argumente dafür herauszufinden ldführen Sie das manuell aus ld Sie wollen mit diesen Argumenten:

cc -c foo.c
cc -v foo.c -o /dev/null

Schauen Sie sich nun den Linker-Aufruf an und kopieren Sie den Linker und die temporäre Objektdatei manuell und fügen Sie sie manuell ein. Etwas in der Art (Beispiel aus einem Test auf Fedora 23), bei dem Sie ersetzen /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/collect2 mit /usr/local/bin/ld (Obwohl es nicht so ist Exakt das Gleiche wie collect2):

/usr/local/bin/ld -plugin /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper -plugin-opt=-fresolution=/tmp/jhein/ccM2XKIg.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1 -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../.. c.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtend.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crtn.o

Wie Sie sehen, ist das nicht einfach. Beachten Sie, dass es auf der GCC-Infoseite eine Dokumentation darüber gibt, wie Collect2 nach einem Linker-Programm sucht. Diesen Dokumenten zufolge ist die erste Stelle, nach der es sucht, jedoch keine Umgebungsvariable oder etwas, das Sie in der Befehlszeile angeben können (z. B. –linker). Die Dokumente sagen, dass es so aussieht Erste für einen „fest codierten Linker-Dateinamen“. Wenn diese Dokumentation korrekt ist, müssten Sie den Standard-Linker umbenennen, um ihn dazu zu zwingen, diesen Linker nicht zu verwenden (d. h. auszutricksen) sudo mv /usr/bin/ld /usr/bin/ld.tmp-disable).

Update 2: Verwenden -B scheint für meine Bedürfnisse gut genug zu funktionieren. Siehe unten, wo ich eine Antwort gepostet habe. Ich kann meine eigene Antwort nicht akzeptieren, aber ich würde es tun, wenn ich könnte – es scheint das Problem gut zu lösen.

Der -B Mit dieser Option können Sie einen alternativen Suchpfad für ausführbare Dateien, Bibliotheken, Include-Dateien und Datendateien angeben, die der Compiler verwenden wird. Dies funktioniert für einige Versionen von gcc [1] und für Clang (derzeit undokumentiert – in Manpages von mindestens Clang 3.7 und 3.8):

cc -B/usr/local/bin foo.c -o foo

Beachten Sie, dass dies dazu führt, dass cc im von angegebenen Pfad nach anderen Tools (z. B. dem Assembler) sucht -B. Angenommen, Sie haben eine andere Version von Binutils in /usr/local/bin installiert, wenn ja nur Ich möchte diesen Linker verwenden (anstatt /usr/local/bin/as, et. al.), könnten Sie so etwas tun:

mkdir /tmp/usemyld
ln -s /usr/local/bin/ld /tmp/usemyld
cc -B/tmp/usemyld foo.c -o foo

-B verfügt über eigene Regeln, mit denen Sie verschiedene Dateien überschreiben können, die der GCC-Compiler zu verwenden versucht (Programme, Bibliotheken, Include-Dateien, Datendateien). Dies ist mindestens seit GCC 2.95 dokumentiert – lesen Sie die GCC-Man-/Infoseiten. Ich weiß nicht, wie kompatibel das Verhalten von ist -B ist für Klirren. Wie bereits erwähnt, ist es derzeit nicht in der Clang-Manpage dokumentiert. Aber es funktionierte so gut, dass ich wie oben gezeigt einen alternativen Linker auswählen konnte.

gcc Unterstützt auch den Aufruf eines Skripts/Programms wie in angegeben -wrapper. clang nicht (derzeit). Sie können dies auch verwenden und auf ein Wrapper-Skript verweisen, das ändert, welches Programm der Compiler aufruft. Ich weiß nicht, ob collect2 beachtet das -wrapper Option (und für gcc, collect2 ruft den Linker zumindest beim Kompilieren von C/C++-Programmen auf).

[1] Die in der dokumentierte Linker-Suchreihenfolge gcc Infoseite für collect2 sagt, dass zuerst nach „einem fest codierten Linker-Dateinamen gesucht wird, wenn GCC mit der Option ‚–with-ld‘ konfiguriert wurde“). Wenn Ihr gcc also nicht mit „–with-ld“ konfiguriert wurde, wird er schließlich in dem von angegebenen Pfad suchen -B (Wenn es nicht gefunden wird real-ld Erste). Wenn Ihr gcc War konfiguriert mit --with-lddann ist die -B Die Option hilft Ihnen nicht dabei, einen alternativen Linker Ihrer Wahl anzugeben.

Bestimmte Linker sind einfach zu verwenden – einfach gcc -fuse-ld=lld main.c. Dies scheint irgendwo in gcc Version 4 hinzugefügt worden zu sein. -fuse-ld funktioniert auch mit clang 10.0.1.

Unterstützte Linker sind auf aufgeführt https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

-fuse-ld=bfd

Verwenden Sie den bfd-Linker anstelle des Standardlinkers.

-fuse-ld=Gold

Verwenden Sie den Gold-Linker anstelle des Standard-Linkers.

-fuse-ld=lld

Verwenden Sie den LLVM-LLD-Linker anstelle des Standardlinkers.

Hoffentlich hilft dies Leuten, die von Suchanfragen kommen, da OP ihre Frage schon vor langer Zeit beantwortet hat.

GCC wird intern verwendet spec-Dateien (um zu entscheiden, wie die gcc Programm verhält sich, insbesondere wie es verlinkt und mit welchem ​​Linker). Das können Sie konfigurieren oder ändern mit -specs= Halten Sie also Ihre eigene Spezifikationsdatei bereit und verwenden Sie diese. Oder nutzen Sie die -T Möglichkeit (von gcc welche ausdrücklich übergibt es an ld), um ein Linker-Skript zu erstellen.

Die Standardspezifikation wird mit erhalten gcc -dumpspecs

Auch von strace(1)-ing einige gcc Befehl, werden Sie feststellen, dass versucht wird, auf z. B. zuzugreifen /usr/lib/gcc/x86_64-linux-gnu/specs; Legen Sie dort also Ihre eigene Spezifikationsdatei ab.

Da es sich bei diesen Spezifikationsdateien um Textdateien handelt, sollten Sie in der Lage sein, Ihre eigenen zu schreiben.

Aber ich bin mir nicht sicher, ob es eine gute Idee ist.

Übrigens, /usr/bin/cc ist auf der Linux-Distribution ein symbolischer Link (auf Debian: /usr/bin/cc -> /etc/alternatives/cc -> /usr/bin/gcc), entweder zu einigen gcc oder zu einigen clang. SO VIEL ICH WEISS, cc (Und c99) ist in POSIX angegeben (aber natürlich wird nichts über seine Beziehung zu gesagt). ld)

Legen Sie das Verzeichnis ab, das den alternativen Linker enthält ld nach vorne PATH Umgebungsvariable.

Zum Beispiel, wenn eine Alternative ld ist in ~/local/bin. export PATH=~/local/bin:$PATH wird verursachen cc benutzen ~/local/bin/ld.