Archiv verlassen und diese Seite im Standarddesign anzeigen : andere gcc-Version verwenden
Ich habe auf meinen Debian Sarge die gcc 2.95 sowie auch gcc 3.3.4. Wenn ich jetzt etwas mit "make" kompilieren möchte, wie kann ich dem System bekannt geben, dass ich statt der gcc 3.3.4 die alte 2.95 nutzen möchte?
Dazu gibt es mehrere Möglichkeiten:
- Makefile anpassen
- Umgebungsvariable setzen: export CC=gcc-2.95
- Symlink zu gcc in /usr/bin ändern
Hi,
ich hab das bei mir auf Debian durch ein kleines Skript gelöst, das
zwischen 3 installierten gcc-Versionen umschaltet (2.95, 3.3 und 3.4).
Es reicht die Anpassung von 3 Symlinks auf eine spezielle Version:
/usr/bin/(gcc|g++|cpp)
Gruss,
Wolfgang
Hallo Leute,
Dazu gibt es mehrere Möglichkeiten:
- Makefile anpassen
- Umgebungsvariable setzen: export CC=gcc-2.95
- Symlink zu gcc in /usr/bin ändern
wie passe ich den Makefile an?
reciht da einfach eine Zeile "CC=gcc-2.95" einzutragen?
Hallo Leute,
wie passe ich den Makefile an?
reciht da einfach eine Zeile "CC=gcc-2.95" einzutragen?
Nein. Fummel nicht im Makefile rum, wenn du nicht weißt was zu tun ist.
Nimm eine andere Möglichkeit, die von Tomek erwähnt wurde.
evtl. postet tictactux ja sein script. ;)
Was heißt denn "Wenn ich jetzt etwas mit make kompilieren möchte"? Handelt es sich um ein autoconf-basiertes Projekt oder geht es um handgeschriebene Makefiles?
Bei autoconf-basierten Projekten setzt man einfach vor dem Aufruf von "./configure" die Umgebungsvariablen "CC" und ggf. "CXX":
env CC=gcc-<version> CXX=g++-<version> ./configure
Bei handgeschriebenen Makefiles geht das meistens auch, manchmal sind die Makefiles aber defekt und nutzen ausgeschriebene Pfade statt Makros. In dem Fall müsste man die Makefiles von Hand reparieren, was in jedem Einzelfall etwas anders geht.
Anders als DaGrrr bin ich der Meinung, dass man, wann immer möglich, zum Kompilieren anderer Pakete nichts tun sollte, das root-Rechte erfordert. Man kann auch ein Verzeichnis "$HOME/bin" anlegen, die gewünschte GCC-Version temporär dorthin verlinken und dieses Verzeichnis dann ganz vorne an den PATH anhängen, damit dieses Verzeichnis vor "/usr/bin" gefunden wird.
Bei autoconf-basierten Projekten setzt man einfach vor dem Aufruf von "./configure" die Umgebungsvariablen "CC" und ggf. "CXX":
env CC=gcc-<version> CXX=g++-<version> ./configure
Bei handgeschriebenen Makefiles geht das meistens auch, manchmal sind die Makefiles aber defekt und nutzen ausgeschriebene Pfade statt Makros. In dem Fall müsste man die Makefiles von Hand reparieren, was in jedem Einzelfall etwas anders geht.
und wie mache ich das jetzt beim kernelkompilieren?
wenn ich in den Makefile vom Kernel
CC=gcc-<version>
CXX=g++-<version>
einfüge verwendet er trotzdem meinen "standard-gcc".
Bei der Kernelübersetzung werden CC und HOSTCC respektiert, also z.B. `make CC=gcc-2.95 HOSTCC=gcc-2.95 oldconfig bzImage modules`.
wenn ich in den Makefile vom Kernel
[...]
einfüge verwendet er trotzdem meinen "standard-gcc".
Dann setz den Absatz meines Postings um, den Du zufällig nicht zitiert hast. Klappt bestimmt. Dadurch wird nämlich ein anderer gcc zum "Standard-gcc" (d.h. zum ersten Binary namens "gcc" im PATH), ohne dass man als root in Systemverzeichnissen rumpfuschen muss.
ich mache es anders ;)
CC=gcc-3.4 ./ati-driver-blablubb.run
mit dieser syntax haut es immer hin, default ist 4.0 hier ;)
grüsse
Silvan
CC=gcc-3.4 ./ati-driver-blablubb.run
Das ist übrigens genau dasselbe, als hätte man die Umgebungsvariable "CC" vor dem Ausführen von "ati-driver-blablubb.run" auf den Wert "gcc-3.4" gesetzt.
hab ich gemacht ich habe "export CC=gcc-3.4" eingegeben aber er verwendet den 4.0.
mir hat es dann gereicht und ich hab einfach den symlink im /usr/bin geändert und dann war alles mit dem gcc wie ich 's wollte.
hehe so mach ichs auch immer. in den makefiles fummel ich ungern rum, was die compiler version angeht... spreche da auserfahrung... nachher mach ich noch was mit den sourcen und s klappt nix mehr wg der dummen änderungen, wenn man zb doch seinen gcc upgedatet hat oder so...
btw... wozu braucht mer denn den gcc-4, wenn ihn keiner verwendet?
ich mag ihn zb net. ;)
btw... wozu braucht mer denn den gcc-4, wenn ihn keiner verwendet?
- es stimmt nicht, dass ihn keiner verwendet
- GCC 4.0 kann man gut brauchen, wenn man Precompiled Headers nutzen will
- GCC 4.0 kann man gut brauchen, wenn man ELF Visibility nutzen will
- GCC 4.0 kann man gut brauchen, wenn man als Entwickler weniger Zeit untätig mit dem Zuschauen beim Kompilieren verbringen will
- GCC 4.0 kann man gut brauchen, wenn man Code haben will, der näher an der herstellerunabhängigen C++-ABI dran und somit kompatibler zu Code von anderen Compilern ist
- GCC 4.0 kann man gut brauchen, wenn man ernsthaft Java-Entwicklung ohne JDK betreiben will
- GCC 4.0 kann man gut brauchen, wenn man ernsthaft Fortran-Entwicklung ohne Intel-Produkte betreiben will
- GCC 4.0 kann man gut brauchen, wenn man nicht früher oder später von der Außenwelt abgeschnitten sein will
ich mag ihn zb net. ;)
Wieso? So langsam aber sicher werden doch nach und nach wirklich die meisten Projekte daran angepasst - in Notfällen kann man immer noch den GCC 3.4 für hartnäckige Problemfälle benutzen und ansonsten den GCC 4.0 nehmen.
ich verwende auch lieber neuere versionen.
ich musste nur in siesem fall gcc 3.4 verwenden, da ich den 2.6.9er kernel compilieren wollte weil ich mir nicht immer nen neuen kernen downloaden kann (ham kein dsl) und der geht mit dem gcc 4 nicht zu compilieren.
mitlerweile hab ich auf ner DVD noch nen 2.6.12er gefunden.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.