(k)ubuntu 12.10, gcc und avr-gcc parallel installieren

Das sollte kein Problem sein, da alle zu AVR-GCC gehörigen Tools den
Prefix "avr-" haben und die Headerfiles und Libraries in einem eigenen
Verzeichnis abgelegt werden. Falls gcc und avr-gcc beide offizielle
kubuntu-Pakete sind, sollte es erst recht keine Konflikte geben.

Wenn man die Pakete selber geeignet baut, kann man sogar mehrere
AVR-GCC-Versionen parallel installieren. Ich habe bspw. sieben
verschiedene AVR-GCC- und eine x86-GCC-Version installiert :)

Unter Windows kann man einfach die PATH-Variable auf das Verzeichnis der 
gewünschten Compilerinstallation setzen.

Man legt sich entsprechende Shortcuts auf den Desktop, die den PATH 
setzen, das Tool aufrufen und danach den alten PATH wieder restaurieren.
Da dieser PATH für die Task lokal ist, kann man sogar verschiedene 
Compiler gleichzeitig öffnen.
Die IDE muß allerdings mehrere Instanzen erlauben.

Unter Linux sollte ähnliches möglich sein.

c. m. schrieb:
> warum verschiedene avr-gcc's wenn ich mal fragen darf?

Hauptsächlich aus Spaß und Interesse. Eine Zeit lang (so ab Version
4.3) hatte ich das Gefühl, dass die Optimierungsfähigkeiten im Vergleich
zu 4.2 immer mehr nachließen. Ich behielt deswegen den 4.2, installierte
aber zusätzlich neuere Versionen, um auch neuere AVRs programmieren zu
können, die vom 4.2 noch nicht unterstützt wurden. Zudem konnte ich so
leichter erkennen, wann die "Qualitätskurve" von der fallenden Phase
wieder in die steigende überging. Seit etwa 4.6 sind die Compiler meinem
Gefühl nach (das ist alles natürlich auch ein wenig subjektiv) wieder
richtig gut geworden¹. Die alten Versionen werde ich aber trotzdem nicht
löschen. Man kann sie noch gut dazu verwenden, um hier im Forum Anfragen
der Art "Ich habe ein problem mit AVR-GCC 4.x.x." zu beantworten ;-)

–––––––––––
¹) Das könnte damit zusammenhängen, dass seit einiger Zeit der hier im
   Forum wohlbekannte Johann (gjlayde) seine Finger im Spiel hat :)

Peter Dannegger schrieb:
> Unter Windows kann man einfach die PATH-Variable auf das Verzeichnis der
> gewünschten Compilerinstallation setzen.
>
> Man legt sich entsprechende Shortcuts auf den Desktop, die den PATH
> setzen, das Tool aufrufen und danach den alten PATH wieder restaurieren.

Solche Umstände sind unter Linux oder Unix-Systemen völlig unnötig. gcc 
unterstützt schon seit jeher die Parallelinstallation beliebig vieler 
Versionen und Zielarchitekturen.

Das Programm "gcc" ist nur ein Wrapper, der den eigentlichen gcc 
aufruft, und zwar die Default-Version für die Default-Architektur. Man 
kann aber jederzeit gezielt einen bestimmten Compiler einer gegebenen 
Version und Architektur mit entsprechendem Prefix (für die Architektur) 
und Postfix (für die Version) aufrufen.

Hier bei mir zum Beispiel ruft gcc etwa x86_64-linux-gnu-gcc-4.7 auf, 
direkt aufrufen kann ich aber auch arm-linux-gnueabi-gcc, 
arm-none-eabi-gcc-4.7.1, avr-gcc, avr-gcc-4.7.2, ... Auch die parallele 
Installation von Distributionspaketen und selbst übersetzten Toolchains 
in /usr/local funktioniert so einwandfrei.

Daher sieht man in Makefiles auch oft diese Variablen für die 
Konfiguration am Anfang:

1

CROSS_COMPILE :=

2

CC  := $(CROSS_COMPILE)gcc

3

CXX := $(CROSS_COMPILE)g++

4

AS  := $(CROSS_COMPILE)as

5

...

Dann muss man nur CROSS_COMPILE setzen und bekommt so die richtige 
Architektur dank des einheitlichen Namensschemas bei gcc und binutils.

Yalu X. schrieb:

> Seit etwa 4.6 sind die Compiler meinem
> Gefühl nach (das ist alles natürlich auch ein wenig subjektiv) wieder
> richtig gut geworden.
>
> Das könnte damit zusammenhängen, dass seit einiger Zeit der hier im
> Forum wohlbekannte Johann (gjlayde) seine Finger im Spiel hat :)

Für die 4.6 nicht, da ging es noch um das Beheben von "richtigen" Bugs, 
d.h. falscher Code etc.

AVR-spezifische Optimierungen gab es vor allem in der 4.7, was dann die 
erste Version war, die den guten alten 3.4.6 in der Codegröße schlagen 
konnte.

Die "einfachen" Optimierungen sind inzwischen so ziemlich alle 
abgegrast. Ob sich irgendjemand mal an den verbliebenen Bodensatz von 
schwierigen Optimierungen macht ist eher unwahrscheinlich...