Gcc-libs scheinbar defekt nach Partial Upgrade / uv sync

EOS Deutsch
1

Hallo,

vor einiger Zeit habe ich aus Versehen den Stecker gezogen bei einem Update. Jetzt musste ich python packages mit uv sync bauen und bekam den Fehler:

/usr/bin/ld: -lgcc_s kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden
collect2: error: ld gab 1 als Ende-Status zurück

Also versuchte ich, das neu zu installieren:

sudo pacman -Syu base-devel gcc glibc

und libgcc_s ist auch vorhanden:

find /usr/lib -name “libgcc_s.so*”
/usr/lib/libgcc_s.so.1

danach ldconfig. Die library scheint an sich gefunden zu werden:

g++ -print-file-name=libgcc_s.so.1
/usr/lib/gcc/x86_64-pc-linux-gnu/16.1.1/../../../../lib/libgcc_s.so.1

aber verwenden kann ich es nicht:

echo ‘int main(){}’ | g++ -x c++ - -lgcc_s -v

/usr/bin/ld: -lgcc_s kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden
collect2: error: ld gab 1 als Ende-Status zurück

weswegen ich auf ein pacman Problem tippe. Ich habe den DB eintrag gelöscht und dann wieder die gleiche Prozedur wie oben:

sudo rm -rf /var/lib/pacman/local/gcc-libs-*

sudo pacman -S gcc-libs --overwrite ‘*’

und noch immer gibt mir

pacman -Ql gcc-libs | head

einen leeren output :frowning: auffällig ist auch, dass beim neu install gcc-libs mir eine 0.00 MiB Änderung anzeigt, d.h das package wird sogar gefunden, nur der link ist irgendwie nicht da.

Was könnte das Problem sein? Was mache ich falsch?

2

Nur als Hinweis, bei dem Befehl:
pacman -Ql gcc-libs | head
Bekomme ich auch keine Meldung.

Installiert ist es:

yay gcc-libs
6 aur/lib32-gcc-libs-snapshot 17.0.0.snapshot20260517-1 (+3 0.00) 
    GNU Compiler Collection - 32-bit Runtime libraries (snapshot)
5 aur/lib32-gcc-libs-git 13.0.0_r197401.g33be3ee36a7-1 (+15 0.00) (Veraltet: 2026-02-22) 
    32-bit runtime libraries shipped by GCC (git version)
4 aur/gcc-libs-snapshot 17.0.0.snapshot20260517-1 (+3 0.00) 
    GNU Compiler Collection - Runtime libraries (snapshot)
3 aur/gcc-libs-git 13.0.0_r197401.g33be3ee36a7-1 (+15 0.00) (Veraltet: 2026-02-22) 
    Runtime libraries shipped by GCC (git version)
2 core/lib32-gcc-libs 16.1.1+r12+g301eb08fa2c5-1 (10.8 MiB 45.0 MiB) (Installiert)
    32-bit runtime libraries shipped by GCC
1 core/gcc-libs 16.1.1+r12+g301eb08fa2c5-1 (2.7 KiB 0.0 B) (Installiert)
    Runtime libraries shipped by GCC

Sollte das nicht ein kleines “i” sein? = -Qi
Bei der Schreibweise bekomme ich ne Meldung.

3

Das ist natürlich ein guter Punkt, danke!

pacman -Qi gcc-libs | head
Name : gcc-libs
Version : 16.1.1+r12+g301eb08fa2c5-1
Beschreibung : Runtime libraries shipped by GCC
Architektur : x86_64
URL : https://gcc.gnu.org
Lizenzen : GPL-3.0-or-later WITH GCC-exception-3.1 GFDL-1.3-or-later
Gruppen : Nichts
Stellt bereit : gcc-libs-multilib
Hängt ab von : glibc>=2.27 libasan libatomic libgcc libgfortran libgomp liblsan libobjc libquadmath libstdc++ libtsan libubsan
Optionale Abhängigkeiten : Nichts

Verwenden kann ich es trotzdem nicht,

echo ‘int main(){}’ | g++ -x c++ - -lgcc_s -v

findet weiterhin kein -lgcc_s. Interessant ist, dass ich das Problem auf einem anderen User auf dem gleichen PC nicht habe? Vielleicht ist das Problem ja hier :confused:

4

Habe die Lösung (aber keine Erklärung) gefunden: uv sync hat in /usr/lib nach der binary libgcc_s.so gesucht, die lag aber bei mir in /usr/bin. Mittels softlink konnte ich dann kompilieren.

Wieso das überhaupt in /usr/bin/ und nicht lib war, ist mir ein Rätsel - vermutlich ein Fehler meinerseits, wie ich gcc bei dem partial update händisch ersetzen musste, damit pacman wieder funktioniert. mMn sollte auch eigentlich /usr/lib/libgcc_s.so.1 ausreichen, aber offenbar ist uv sync da happig.

Wieso das auf einem User geht und auf dem anderen nicht, finde ich aber am seltsamsten. Google Gemini sagt dazu:

Es gibt eine Besonderheit bei Tools wie uv (oder ähnlichen Python/Rust-Paketmanagern) sowie Toolchains wie Julia oder ROCm. Einige dieser Tools bringen eigene isolierte GNU-Umgebungen (oft via sysroot) mit. Wenn der andere User diese Tools nicht nutzt oder eine andere Konfiguration geladen hat, greift sein g++ auf ein anderes Verzeichnis zu, in dem die Datei liegt, oder er nutzt das Multilib-Paket.

Auf einem sauberen Arch Linux wird libgcc_s.so vom Paket gcc bereitgestellt. Da du gcc bereits neu installiert hast, vermute ich, dass bei deinem aktuellen User ein Tool wie uv oder ein Conda/Julia-Environment aktiv im Hintergrund läuft und GCC via sysroot auf ein alternatives, unvollständiges Verzeichnis umleitet.

Trotzdem danke für jeden Hinweis <3