Nicht standardmäßige G ++-Umgebung kann nicht libc_nonshared finden.a ⇐ C++

[Anonymous]

Ziel
Ich erstelle eine tragbare Linux-C ++-Umgebung für einen Kurs, um Sudo Bürokratie auf unserer Website zu vermeiden und über eine vorgefertigte Lösung mit VSCODE enthalten zu sein. Ich habe dies mit Erfolg für einen Python-Kurs und einen Julia-Kurs gemacht (siehe Juliawin), aber G ++ scheint ein anderes Tier zu sein. libblas-dev ) zusammen mit ihren Abhängigkeiten und extrahierte es in ein Pseudo-Root-Verzeichnis, z.


Umgebungsumschlagstruktur
is. In diesem Skript habe ich eine Reihe von Umgebungsvariablen für unsere Build -Tools festgelegt, um alle in diesem System enthaltenen Header und Bibliotheken aufzunehmen. Insbesondere habe ich ld_library_path , bibliothek_path , c_library_path , cplus_library_path , cmake_library_path , include , c_include>, cplus_include, , cmake_paths>, cmake_pathops, festgelegt. Cmake_prefix_path , path , cc und cxx . Z.B. Wenn ich welches g ++ eingeben kann, erhalte ich den tragbaren Ort:

Code: Select all

/home/emdw/Downloads/portable_cpp/linux/usr/bin/g++
< /code>
Ermöglicht mir auch, dass der Linker mit allen gebündelten Bibliotheken, freigegebenen Bibliotheken und Headern verlinkt wird. Ld 

wirft jedoch weiterhin einen Verknüpfungsfehler für einen scheinbar festen Standort /usr/lib/x86_64-linux-nu/libc_nonshared.a . Dies ist die Ausgabe, die ich bekomme, wenn ich dieses Beispiel für die Hello -Welt zusammenstelle: < /p>

Code: Select all

$ g++ hello.cpp -o hello
/usr/bin/ld: cannot find /usr/lib/x86_64-linux-gnu/libc_nonshared.a
collect2: error: ld returned 1 exit status

Das Symptom
Wenn ich einen Symlink aus meinem gebündelten libc_nonshared.a zum Systempfad:
mache

Code: Select all

sudo ln /home/emdw/Downloads/portable_cpp/linux/usr/lib/x86_64-linux-gnu/libc_nonshared.a /usr/lib/x86_64-linux-gnu/libc_nonshared.a -s

Dann kann ich erfolgreich Hello.cpp
kompilieren

Code: Select all

$ g++ hello.cpp -o hello
$ ./hello
Hello world!

Da ich an einem sauberen Linux-Mint-VM ohne installierte Software arbeite, kann ich bestätigen, dass dies tatsächlich eine erfolgreiche Zusammenstellung aus meiner tragbaren Pipeline mit nur libc_nonshared.a als nicht portable hartcodierte Komponente ist. Dies ist offensichtlich keine Lösung, sondern nur eine Möglichkeit, auf das eigentliche Problem zu verweisen.>