C++ Compiler g++ fehlt nach der Installation von g++-14
Hallo, ich habe ein Tumbleweed 64 Bit Snapshot (openSUSE-Tumbleweed-DVD-x86_64-Snapshot20231222-Media.iso) verwendet um darauf meine Software zu kompilieren und anzutesten. Leider wird der g++14 Compiler ohne symlink angelegt und die wxWidgets Quellen fragen nach diesem. Mir ist nicht bekannt dass das in der Vergangenheit mal nicht ging. Ist jemandem das Problem bekannt? Ist es wxWidgets oder die Distro die da was anders machen? PS: Ich hatte zuvor die OpenSuSE Tumbleweed rpms - glaube wxgtk2 angetestet, diese haben aber ein Problem beim Linken meiner Software: cc `wx-config --inplace --libs` -lwx_gtk3u_aui-3.2 -lwx_gtk3u_propgrid-3.2 -o wxWrapper dynamic.o -ldl -lstdc++ -L/home/lothar/lib -llbHook -lwxWrapperDLL /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/libtiff.so.6: undefined reference to `jpeg12_read_raw_data@LIBJPEG_8.0' /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/libtiff.so.6: undefined reference to `jpeg12_write_raw_data@LIBJPEG_8.0' /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/libtiff.so.6: undefined reference to `jpeg12_read_scanlines@LIBJPEG_8.0' /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/libtiff.so.6: undefined reference to `jpeg12_write_scanlines@LIBJPEG_8.0’ Kann mir da jemand weiterhelfen? Ich erwarte eigentlich, dass der gcc und g++ mit einer Variante 13 oder 14 auch die Symlinks anlegen (weil ich das aus Nutzersicht testen will). Oder habe ich zu lange kein Linux mit Compiler mehr eingerichtet und hier sich was geändert hat? :-) Danke, Lothar
Hallo Lothar, hallo zusammen, Am Samstag, 23. November 2024, 13:31 schrieb Lothar Behrens:
ich habe ein Tumbleweed 64 Bit Snapshot (openSUSE-Tumbleweed-DVD-x86_64-Snapshot20231222-Media.iso) verwendet um darauf meine Software zu kompilieren und anzutesten.
Leider wird der g++14 Compiler ohne symlink angelegt
Der Symlink steckt in einem anderen Paket. # ls -l /usr/bin/g++* lrwxrwxrwx 1 root root 6 23. Sep 18:34 /usr/bin/g++ -> g++-14* -rwxr-xr-x 1 root root 1181624 9. Okt 15:01 /usr/bin/g++-14* # rpm -qf /usr/bin/g++* gcc-c++-14-2.1.x86_64 gcc14-c++-14.2.1+git10750-1.1.x86_64 # rpm -qvl gcc-c++ lrwxrwxrwx 1 root root 6 Sep 23 18:34 /usr/bin/c++ -> g++-14 lrwxrwxrwx 1 root root 6 Sep 23 18:34 /usr/bin/g++ -> g++-14 lrwxrwxrwx 1 root root 11 Sep 23 18:34 /usr/share/man/man1/c++.1.gz -> g++-14.1.gz lrwxrwxrwx 1 root root 11 Sep 23 18:34 /usr/share/man/man1/g++.1.gz -> g++-14.1.gz Ich vermute mal, dass ein zypper in gcc-c++ helfen sollte ;-) Gruß Christian Boltz -- Ich weiß nicht, wieso ihr euch so echauffiert. Die Warnung ist doch wirklich deutlich zu lesen auf der Packung. Da steht in großen, deutlichen Lettern: "Microsoft". NATÜRLICH funktioniert das nicht. Mehr als warnen können sie euch nicht. [Fefe in de.alt.sysadmin.recovery]
Danke für die Info. Ich habe nochmals alles neu installiert - inclusive system und habe nun das richtige Paket erwischt. Die verschiedenen Versionen des Compilers installieren offenbar nicht den Symlink in der Annahme automatisch mit, dass ich dann auch die neu installierte Version gerade verwenden will. Auf dem Mac kann ich die toolchain selektieren. Glaube in Linux gibt es das nicht. Habe auch mit der VM einige andere Probleme. Yast scheint seine DB zerschossen zu bekommen durch zypper oder sonst was. Früher ist sowas nicht passiert und ich konnte zypper paralell verwenden. Vielleicht ist es aber auch was Anderes (eben ein snapshot). Die Bildschirm Einstellung scheint auch flöten zu gehen (FullHD) und die Einstellung dessen startet über das Kontextmenü des Desktops nicht mehr. Habe die Pakete aktualisiert, die mir angeboten werden. Werde mal auf eine etwas ältere Tumbleweed gehen. Hab eine auf einem extra Notebook (HP Elitebook 8440p), welche stabil läuft. Ist also entweder VM HyperV oder der Snapshot. Wie das werden wird, wenn ich erst noch den SuSE Build Server nutze und was da noch alles nötig wird, weiß ich nicht. Jedenfalls versuche ich mein Release Distro tauglich zu machen :-) Gruß Lothar
Am 23.11.2024 um 19:02 schrieb Christian Boltz <suse@cboltz.de <mailto:suse@cboltz.de>>:
Am 24.11.24 um 10:36 AM schrieb Lothar Behrens:
Habe auch mit der VM einige andere Probleme. Yast scheint seine DB zerschossen zu bekommen durch zypper oder sonst was. Früher ist sowas nicht passiert und ich konnte zypper paralell verwenden.
yast verwendet keine DB. Es spricht nichts dagen, yast und zypper wechelseitig zu benutzen. Wenn Dein yast sich ungewöhlich verhält und Du an der Ursachenforschung interiessiert sein solltst, wäre etwas mehr Inpit hilfreich. Viele Grüße Ulf
Am 24.11.24 um 18:53 schrieb Ulf Volmer:
yast verwendet keine DB.
Aber der darunterliegende rpm. Eine kaputte rpm-Datenbank sollte man mit rpmdb --rebuild reparieren können Sowohl zypper als auch yast verwenden libzypp. Und da wird jeweils ein Lock gesetzt so daß immer nur eines der Programme laufen kann
Am 24.11.24 um 7:19 PM schrieb Markus Koßmann:
Am 24.11.24 um 18:53 schrieb Ulf Volmer:
yast verwendet keine DB.
Aber der darunterliegende rpm. Eine kaputte rpm-Datenbank sollte man mit rpmdb --rebuild reparieren können
Sowohl zypper als auch yast verwenden libzypp. Und da wird jeweils ein Lock gesetzt so daß immer nur eines der Programme laufen kann
Lothar hatte die Theorie, dass die paralelle Verwendung von yast und zypper die 'yast DB' zerschießen würde. Passen Deine Ausführungen da rein? Viele Grüße Ulf
Markus Koßmann schrieb:
Am 24.11.24 um 18:53 schrieb Ulf Volmer:
yast verwendet keine DB.
Aber der darunterliegende rpm. Eine kaputte rpm-Datenbank sollte man mit rpmdb --rebuild reparieren können
Das reicht aber meistens nicht. Die DB ist zwar hinterher Datenbank-technisch wieder konsistent, das heißt aber nicht, dass sie auch korrekt ist. Bei mir war es mal so, dass einige Einträge mehrfach vorhanden waren, also bestimmte Pakete in derselben Version angeblich mehrfach installiert waren, was dann bei Updates dieser Pakete zu Fehlermeldungen geführt hat. Die habe ich dann deinstalliert und neu installiert, dann war der Spuk weg. Bei kritischen Paketen sollte man noch schauen, dass es nicht eine Deinstallations-Routine gibt, die irgendwelche wichtigen Konfiguration "weg haut" bzw. diese vorher sichern. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
participants (5)
-
Christian Boltz -
Lothar Behrens -
Manfred Haertel, DB3HM -
Markus Koßmann -
Ulf Volmer