Am Mit, 2002-10-23 um 19.42 schrieb Philipp Thomas:
Ralf Corsepius
[23 Okt 2002 16:26:39]: (gcc nach /usr/local zu installieren bedeutet den Systemcompiler zu ersetzen und nicht, wie viele fälschlicherweise annehmen "parallel zu installieren" - /usr/local ist eben NICHT der universelle Ort zur Installation.)
Im Prinzip gebe ich dir ja Recht, aber auf /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/ greift *nur* ein gcc 2.95 zu, der für exakt dieses target-tripple (i686-pc-linux-gnu) konfiguriert wurde! Sofern der gcc entweder für ein Anderes Target konfiguriert wird oder aber sich in der Version unterscheidet, geht die Sache gut. Da hst Du im Prinzip recht, aber ...
Meine Theorie ist folgende: Der Fragesteller hatte auf einer älteren SuSE (7.x, 8.0) eine "vanilla"-gcc Installation durchgeführt. Folge: Eine gcc-Installation mit ihrer kompletten Infrastruktur (inklusive "fixed-includes") unter /usr/local. Danach hatte er einen Update auf SuSE-8.1 ausgeführt. Folge: Die "System-Includes/Libs" (/usr/[lib|include]) wurden ausgetauscht, der "Secondary-gcc" in /usr/local aber nicht. Folge: Da /usr/local/bin normalerweise vor /usr/bin in $PATH steht, verwendet er weiterhin seinen /usr/local/bin/gcc, hat aber dessen unterlagertes System (insb. "fixed-includes") zerstört.
Ich spreche da aus Erfahrung, denn lange habe ich so parallel 2.95 und gcc CVS bzw. 3.X gefahren bzw. fahre jetzt 3.2 und CVS parallel und das ohne jegliche Probleme. Ich auch ;). Ich hatte bis vor kurzem gcc-2.95.x und verschiedene gcc-3.xe parallel installiert, habe derzeit noch ca 10 verschiedene gcc-Cross-Compiler installiert und arbeite gelegentlich mit gcc auf Solaris.
Nur, der Versuch einer Parallelinstallation nach /usr/local funktioniert ohne weitere (komplexere) Eingriffe in die Konfiguration des gcc definitiv nicht (/usr/local/[include|lib] sind Bestandteil des System-Include bzw. Library-Paths. Bei g++ bzw. libstdc++ wird es noch schwieriger, da die libstdc++ versucht ein gemeinsames Verzeichnis für verschiedene Targets zu verwenden (Die Folgen sind dramatisch, wenn man mehrere Cross-gccs mit gemeinsamem prefix installiert, Abhilfe: --enable-version-specific-runtime-libs) Ralf