# Gcc 4.1 ?

## ConiKost

Hallo!

Ich überlege auch bei mir auf meinem Rechner von GCC 3.4.5 auf GCC 4.1.0 umzusteigen ...

Ich nutze komplett ~x86 ... Xorg 7.0 habe ich auch bereits im Einsatz, was meint ihr? Lohnt es sich?

----------

## amne

4.1.0 ist momentan noch hart maskiert, sofern du dich nicht sehr sicher im Umgang mit Compilern fühlst, deine Probleme selbstständig lösen kannst und eventuell sogar Patches für nicht funktionierende Pakete auf bugs.gentoo.org posten kannst/willst/wirst könntest du in Probleme laufen, bei denen dir keiner helfen kann oder wird.

----------

## ConiKost

 *amne wrote:*   

> 4.1.0 ist momentan noch hart maskiert, sofern du dich nicht sehr sicher im Umgang mit Compilern fühlst, deine Probleme selbstständig lösen kannst und eventuell sogar Patches für nicht funktionierende Pakete auf bugs.gentoo.org posten kannst/willst/wirst könntest du in Probleme laufen, bei denen dir keiner helfen kann oder wird.

 

Also auf einem Testrechner konnte ich so gut wie alle Pakete für mich selbst kompilieren  :Smile: 

Nur eine Frage, sind die aktuellen NVidia Treiber kompatibel mit GCC 4.1.0 ?

----------

## Haldir

Yo sind sie, ich hab hier ein amd64 64bit system laufen mit gcc 4.1, xorg 7.0, glibc 2.4 usw. Mach erstmal nen Update auf gcc 4.0, wenn das funktioniert, funktioniert 4.1 auch, das Gegenteil gilt zu 90% auch.

----------

## smg

 *ConiKost wrote:*   

>  *amne wrote:*   4.1.0 ist momentan noch hart maskiert, sofern du dich nicht sehr sicher im Umgang mit Compilern fühlst, deine Probleme selbstständig lösen kannst und eventuell sogar Patches für nicht funktionierende Pakete auf bugs.gentoo.org posten kannst/willst/wirst könntest du in Probleme laufen, bei denen dir keiner helfen kann oder wird. 
> 
> Also auf einem Testrechner konnte ich so gut wie alle Pakete für mich selbst kompilieren 
> 
> Nur eine Frage, sind die aktuellen NVidia Treiber kompatibel mit GCC 4.1.0 ?

 

ausprobieren..

----------

## reptile

die 8178 sind zumindest kompatibel mit dem 4.0

----------

## Tyler_Durden

 *ConiKost wrote:*   

> Lohnt es sich?

 

Das ist eine rein subjektive Frage. Ich musste mein System wegen Platformwechsel komplett neu aufsetzen und setze nun ug. Konfiguration ein. Von ~1000 Paketen hatte ich mit ca. 20 kleinere Probleme, die recht schnell lösbar waren. Viele Entwickler habe ihren Code mittlerweile -soweit nötig- angepasst, evtl. findet sich diese Anpassung aber auch erst in noch maskierten -bzw. cvs/svn-Versionen. Es gibt dazu mind. 2 recht interessante Diskussionen hier  und hier. Der gcc-3.4.5 sollte aber besser noch mit an Bord bleiben, man kann hier ja problemlos mal notfalls umswitchen.

Richtig interessant wird die Kombination dann mit "-fvisibility-inlines-hidden" und den neueren LDFLAGS, insbesondere "-Wl,-Bdirect", die bei fetten Paketen wie QT/KDE (Overlays erforderlich) schon einiges bringen. Wie gesagt: Hilfe gibts aber nur in den speziell vorgesehenen Topics. Probleme mit den Nvidia-Treibern habe auch ich keine, das System läuft soweit auch absolut stabil.

```
Portage 2.1_pre6-r3 (default-linux/amd64/2006.0, gcc-4.1.0, glibc-2.4-r0, 2.6.15-nitro3 x86_64)

=================================================================

System uname: 2.6.15-nitro3 x86_64 AMD Athlon(tm) 64 Processor 4000+

Gentoo Base System version 1.12.0_pre16

dev-lang/python:     2.3.5, 2.4.2-r1

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.59-r7

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1

sys-devel/binutils:  2.16.91.0.6

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r3

ACCEPT_KEYWORDS="amd64 ~amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=k8 -O2 -pipe -msse3 -fomit-frame-pointer"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/env.d"

CXXFLAGS="-march=k8 -O2 -pipe -msse3 -fomit-frame-pointer -ffriend-injection -fvisibility-inlines-hidden"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo"

LANG="de_DE.UTF-8"

LC_ALL="de_DE.UTF-8"

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-Bdirect -Wl,--as-needed -Wl,-hashvals -Wl,-zdynsort"

LINGUAS="de"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/gnome-experimental /usr/local/overlays/xgloverlay"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="amd64 X a52 aac aalib acl acpi alsa amd apache2 apm arts artswrappersuid audiofile avi bash-completion berkdb bitmap-fonts blas bluetooth bzip2 cairo cdr cli crypt css ctype cups curl dba dbus dga directfb dpms dri dts dvb dvd dvdnav dvdr dvdread eds emboss emul-linux-x86 encode esd exif expat fam fastbuild fbcon fbsplash ffmpeg firefox flac font-server fontconfig foomaticdb force-cgi-redirect fortran ftp gd gif gimp gimpprint glx gnome gphoto2 gpm gs gstreamer gtk gtk2 hal icq ieee1394 imagemagick imlib ipv6 java jce jpeg kde kdeenablefinal lame lapack ldap libcaca live lm_sensors logitech-mouse logrotate lzw lzw-tiff mad memlimit mozilla mozsvg mp3 mpeg musicbrainz ncurses nls nntp nptl nptlonly nsplugin ntfs nvidia offensive ogg oggvorbis opengl pam pcre pdf pdflib perl pertty png posix ppds python qt quicktime readline real risky rtc sblive scanner sdl session simplexml slang smp soap sockets spell spl ssl svg symlink tcltk tcpd threads tiff tokenizer truetype truetype-fonts type1 type1-fonts udev unicode usb userlocales v4l v4l2 visualization vorbis x264 xcomposite xext xfs xine xinerama xml xmms xosd xpm xprint xsl xv xvid xvmc zlib elibc_glibc input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_-acecad input_devices_-aiptek input_devices_-calcomp input_devices_-citron input_devices_-digitaledge input_devices_-dmc input_devices_-dynapro input_devices_-elo2300 input_devices_-elographics input_devices_-fpit input_devices_-hyperpen input_devices_-jamstudio input_devices_-joystick input_devices_-magellan input_devices_-magictouch input_devices_-microtouch input_devices_-mutouch input_devices_-palmax input_devices_-penmount input_devices_-spaceorb input_devices_-summa input_devices_-synaptics input_devices_-tek4957 input_devices_-ur98 input_devices_-vmmouse input_devices_-void kernel_linux linguas_de userland_GNU video_cards_nvidia video_cards_-apm video_cards_-ark video_cards_-ati video_cards_-chips video_cards_-cirrus video_cards_-cyrix video_cards_-dummy video_cards_-fbdev video_cards_-fglrx video_cards_-glint video_cards_-i128 video_cards_-i740 video_cards_-i810 video_cards_-imstt video_cards_-mga video_cards_-neomagic video_cards_-newport video_cards_-nsc video_cards_nv video_cards_-rendition video_cards_-s3 video_cards_-s3virge video_cards_-savage video_cards_-siliconmotion video_cards_-sis video_cards_-sisusb video_cards_-sunbw2 video_cards_-suncg14 video_cards_-suncg3 video_cards_-suncg6 video_cards_-sunffb video_cards_-sunleo video_cards_-suntcx video_cards_-tdfx video_cards_-tga video_cards_-trident video_cards_-tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_-via video_cards_-vmware video_cards_-voodoo"

Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS

```

----------

## energyman76b

hm, laß mal überlegen:

gcc4 ist arschlangsam im Vergleich zu gcc3.4

gcc4 ist noch immer ganz schön verbuggt.

gcc4 baut langsameren code als 3.X (schau mal bei Anandtech vorbei, die haben einige interessante Zahlen)

gcc4 baut nicht alles, was gcc 3.4 baut.

Kurz, gibt nicht einen guten Grund auf gcc4 umzusteigen.

----------

## ConiKost

 *energyman76b wrote:*   

> hm, laß mal überlegen:
> 
> gcc4 ist arschlangsam im Vergleich zu gcc3.4
> 
> gcc4 ist noch immer ganz schön verbuggt.
> ...

 

Also KDE 3.5.1 ist mit GCC 4.1 subjektiv ein stück schneller ...

----------

## SinoTech

 *energyman76b wrote:*   

> hm, laß mal überlegen:
> 
> gcc4 ist arschlangsam im Vergleich zu gcc3.4
> 
> gcc4 ist noch immer ganz schön verbuggt.
> ...

 

Also der gcc-4.0.X erzeugt etwas langsameren Code als der 3.4.X, aber der 4.1.X sollte da wieder besser sein.

Verbuggt? Also bei mir läuft er ohne probleme, und das einzige Paket mit dem ich bisher Probleme hatte war qemu (Kann man aber übner Umwege zum kompilieren bewegen). Ansonsten läuft es echt cremig  :Smile: .

Ach ja, LDFLAGS wie bdirect, hashval, ... sollten da auch noch einiges an Geschwindigkeit beim Programmstart rausholen (Aber natürlich auch ein paar probleme machen. Also Finger davon lassen wenn man ein stabiles System will  :Wink: ).

Mfg

Sio

----------

## amne

 *energyman76b wrote:*   

> 
> 
> gcc4 ist arschlangsam im Vergleich zu gcc3.4
> 
> gcc4 ist noch immer ganz schön verbuggt.
> ...

 

Hehe, erinnert mich an die Umstellung gcc 2.9x auf gcc 3.  :Wink: 

Ich werde vermutlich auch erst auf 4.1 umsteigen wenn er stable wird.

----------

## firefly

 *Quote:*   

> gcc4 baut nicht alles, was gcc 3.4 baut.

 

das liegt bestimmt zum großteil an den sourcen und nicht am compiler, da der gcc-4.X noch einiges standard-konformer arbeitet als die 3.4.X versionen.

Es könnte aber sein das im gcc-4.0.X probleme gibt. Das möchte ich nicht bestreiten.

Aber diese aussage ist, so wie sie da steht, nicht ganz richtig. (da diese aussage impliziert, das das Problem nur am gcc-4.0.X selber liegt)

Gruß

Firefly

----------

## energyman76b

@firefly

am Ende ist es egal, ob der Compiler schuld ist, oder die Applikation, wenn dein Lieblingsprogramm damit nicht, aber mit älteren compilerversionen baut.

----------

## SvenFischer

Wo bitte finde ich einen Vergleich von GCC 3.4.x + 4.0.x + 4.1.x?

----------

## Knieper

Im letzten Linux-Magazin (06/06).

Nebenbei:

 *Quote:*   

> 
> 
> Gentoo Weekly Newsletter: 22 May 2006
> 
> GCC 4.1 on its way into Portage
> ...

 

----------

## michel7

Ist GCC der im Laufe dieser Woche freigegeben wird, genau der gleiche der im Moment hardmasked ist?

----------

## amne

Nein, freigegeben wird 4.1.1. Bei der momentan maskierten Version handelt es sich um 4.1.0 bzw die pre-releases für 4.1.1. 

Siehe auch http://packages.gentoo.org/packages/?category=sys-devel;name=gcc

----------

## hoschi

 *energyman76b wrote:*   

> hm, laß mal überlegen:
> 
> gcc4 ist arschlangsam im Vergleich zu gcc3.4
> 
> gcc4 ist noch immer ganz schön verbuggt.
> ...

 

Wenn jeder so denken wuerde....

GCC-4.1 produziert wenn ueberhaupt schnellere Binarys, was sich auch aus subjektiven Berichten zumindest nachvollziehen laesst, wobei man sich in der letzten oder vorletzten c't/linux-mag(?) die Fortschritte ansehen konnte (langsamer ist da nichts geworden, wenn ich mich recht entsinne). Ausserdem ist der C++ Support verbessert worden, und der Compiler rueckt naeher an sauberen C/C++ Code* heran (was vielleicht mal aerger macht, aber eindeutige positiv ist).

*Meines wissen wurden ein paar GNU C/C++-Erweiterungen zum Teufel geschickt, ich weiss auch nicht ob es jetzt nur C++ oder auch C.

Der Wechsel ist soweit Problemlos, und man muss hoechstens (inzwischen unwahrscheinlich) mal auf ein Testing-Paket zurueckgreifen. Der GCC 4.1.1 wird diese Woche sowieso demaskiert, sobald die finalle Version erscheint. Der Sprung von GCC 3.3 auf GCC 3.4 war uebrigens weitaus kritischer (-> libstdc)

PS: Schnelleres Kompilieren ist wenn dann nur fuer Programmierer sinnvoll, wer danach aber eine Compiler bewertet ist auf dem Holzweg. Dann wuerde man mit Interpretersprachen ein OS programmieren, das langsamste der Welt.

----------

## michel7

 *amne wrote:*   

> Nein, freigegeben wird 4.1.1. Bei der momentan maskierten Version handelt es sich um 4.1.0 bzw die pre-releases für 4.1.1. 
> 
> Siehe auch http://packages.gentoo.org/packages/?category=sys-devel;name=gcc

 

Schade, ich würde gerne Gentoo neuaufsetzen. Und wenn möglich gleich mit dem neuen Compiler. Gibts evtl einen genaueren Termin, wann er rauskommt?

----------

## hoschi

Das duerfte ganz und gar nur von den GNU-Entwicklern abhaengen, die den GCC programmieren  :Smile: 

----------

## lxg

Das Thema wird übrigens auch im englischsprachigen Teil diskutiert.

Falls jemand noch weitere Meinungen lesen möchte.

----------

## michel7

Jetzt ist es offiziell im Portage drin!

----------

## Djon

Hallo!!!

Und wird gleich emerged  :Smile: 

PS: Da ich mit mit den CFLAGS nicht so auskenne, bräuche ich eure Hilfe. Welche CFLAGS sind für Pentium M empfehlenswert?

Vielen Dank im Voraus!!!

Mfg Djon

----------

## amne

 *Djon wrote:*   

> PS: Da ich mit mit den CFLAGS nicht so auskenne, bräuche ich eure Hilfe. Welche CFLAGS sind für Pentium M empfehlenswert?
> 
> 

 

Die selben wie bei gcc 3.x - also sowas in der Art:

```
CFLAGS="-march=pentium-m -O3 -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

```

Ob jetzt -O2 oder -O3 kann man streiten, ob man -fomit-framepointer reinnimmt ebenso, aber alles andere ist Humbug.  :Cool: 

----------

## Djon

Ok, danke!!! Ich habe nämlich bei einigen gesehen, dass sie alle nur mögliche CFLAGS dort reingeschrieben haben.

Mfg Djon

----------

## amne

Ja, das geht dann eine Zeit lang gut und irgendwann treten dann seltsame Compilerfehler auf und/oder das System geht gleich ganz kaputt.  :Wink: 

----------

## Klaus Meier

@Tyler_Durden

Bin gerade dabei, mein System auf den gcc 4.1.1 umzustellen. Habe dabei mal deine CFlags und LDFlags probiert. Deine LDFlags machen bei mir bei libperl und den module-init-tools Probleme. Dann hab ich sie rausgeschmissen. Kann sein, daß noch mehr hakt.

----------

## Aldo

 *amne wrote:*   

> 
> 
> ```
> CFLAGS="-march=pentium-m -O3 -pipe -fomit-frame-pointer"
> 
> ...

 

Ich hab noch -fstack-protector mit drin und kaum Probleme festgestellt.

Das einzige was damit nicht läuft: flightgear

Kompiliert zwar, aber läuft dann nicht.

Beendet sich mit "Stacksmashing".

----------

## SvenFischer

Also beim Überfliegen des Linux-Magazins war der GCC 4.1 selten besser als ein 3.4er (schneller im kompilieren/Codegeschwindigkeit). Den Hype kann mann also beruhigt abwarten, bis ale Pakete im stable auch problemlos sich kompilieren lassen.

----------

