# [CFLAGS] gcc-4.1.1 arrive en ~x86 !

## guilc

Voila, donc un petit topo sur les nouveautés à mettre ou pas mettre dans ses cflags.

Pour la mise a jour, je me suis dit : aller hop, on va activer la vectorisation, c'est quand meme LA nouveauté de gcc 4 ! donc j'ajoute un petit "-ftree-vectorize" innocent à mes cflags.

Premère bonne surprise : gcc4 va beaucoup plus vite sur le C (le gain est moins visible sur le C++).

Pour en profiter, un petit coup de emerge -e world... Et la, c'est le drame, TOUTES les applis gtk qui plantent, alors que toutes mes applis kde/ligne de commande... etc fonctionnent au quart de poil soit dit en passant  :Wink: 

Après quelques investigations, le probleme vient d'une segfault au fin fond de fontconfig ! etrange d'ailleurs que seules les applis gtk en soient la victime ! Mais bon...

Dans le doute, je retire -ftree-vectorize de mes CFLAGS, emerge -e world, et la... Ben les applis GTK remarchent !

Donc quels sont vos retours d'expérience sur la vectorisation avec gcc4 ? pas mature ? buggué chez vous aussi ?

----------

## Anthyme

Je suis en emerge -e world ... encore 300 paquet sur 914 ... je perd patience ^^

pour le moment pas de problemes ...

----------

## Jim Gentoo

Bonjour,

Moi, j'ai 391 paquets.... Depuis hiers, ca compile fort....

Par contre, j'ai un monbre assez conséquent d'erreurs... 

Jusqu'a maintenant, j'ai toujours repris avec un emerge --resume --skipfirst mais ca ne va peut-être pas être très propre à la fin   :Confused: 

----------

## guilc

Pour ma part, les seuls paquets qui ne compilent pas sont gimp et netpbm.

J'ai pas encore eu le temps d'investiguer plus en profondeur sur la cause de la non-compilation par contre (pour gimp, ça semble venir de craderies dans le code, avec le USE mmx, mais je jure de rien pour le moment, je reporterai quand j'aurais le temps)

----------

## Anthyme

moi j ai lancé un script

```
emerge -e world

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst
```

 :Laughing: 

certaine chose ne sont pas passé du coté java mais c parce qu'il n'as pas pu redl la sunjdk tout seul normallement ... j'ai remis sun-jdk et les paquets raté compilent pour l'instant...

----------

## kopp

Effectivement le ftree-vectorize pose quelques problèmes. fontconfig par exemple : ça faisait planter firefox et thunderbird (qui n'avaient pas encore été recompilés eux par contre)

Ensuite, zlib faisait planter encore thunderbird sur quelques mails

Et puis openssl faisait planter OpenOffice 2 pour la demande de lecture de licence etc au premier lancement.

Après recompilation sans ce cflags, des trois paquets, plus de problème....

Bref, pour le moment, moi, je bannis !

----------

## guilc

 *kopp wrote:*   

> Effectivement le ftree-vectorize pose quelques problèmes. fontconfig par exemple : ça faisait planter firefox et thunderbird (qui n'avaient pas encore été recompilés eux par contre)
> 
> Ensuite, zlib faisait planter encore thunderbird sur quelques mails
> 
> Et puis openssl faisait planter OpenOffice 2 pour la demande de lecture de licence etc au premier lancement.
> ...

 

Ouf, rassuré de ne pas être le seul a avoir des déboires avec ftree-vectorize  :Wink: 

Tiens, je suis étonné de ne pas avoir de retours de k_s : t'avais fait des essais pourtant non ? ça fait un moment que tu tourne en gcc-4 il me semble !

Un retour sur ce flag, d'autres cflags sympas qui activent une nouvelle fonction et qui est safe ?

----------

## kernelsensei

 *guilc wrote:*   

> Tiens, je suis étonné de ne pas avoir de retours de k_s : t'avais fait des essais pourtant non ? ça fait un moment que tu tourne en gcc-4 il me semble !
> 
> Un retour sur ce flag, d'autres cflags sympas qui activent une nouvelle fonction et qui est safe ?

 

Oui oui, euh moi euh, ouais je suis pas trop actif ces derniers temps, mais je suis toujours vivant, donc faut pas s'inquieter si je reponds pas tout de suite (que ca soit pour donner une info ou bien pour faire chier les gens avec le titre) !

Donc oui je suis en 4.1 et oui ya des merdes avec ftree-vectorize, j'en ai eu un peu marre de jongler, donc pour l'instant je l'ai désactivé ! Par contre il y a un paquet qui ne passe pas du tout avec gcc-4.1 c'est qemu  :Sad: 

Bref, c'est pas encore la grosse joie, mais ca devrait s'arranger  :Wink:  (enfin j'espere)... et a part le ftree-vectorize, je ne connais pas de nouveaux trucs a ajouter malheureusement.

----------

## titoucha

J'utilises gcc4.x depuis un moment et je n'ai pas eu de problème avec -ftree-vectorize.

Il faut dire que j'ai une config un peu spéciale, je suis en 64bits exclusif (pas de multilib) avec glibc en nptlonly donc je n'ais pas OpenOffice et tout programmes qui est 32bits exclusif.

J'ai des CFLAGS simples, je vous les mets. 

```
CFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer -ftree-vectorize"

CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -Wl,-Bdirect"

```

----------

## Anthyme

prelink ne passe plus depui sque je usis en gcc4 ...

```
yeindal htdocs # prelink -amR

prelink: /usr/bin/gnome-about-me: Could not find one of the dependencies

prelink: Can't walk directory tree /usr/lib/: Trop de niveaux de liens symboliques
```

le probleme a l'air simple ... mais comment le résoudre ?

----------

## guilc

Aucun problème de prelink ici, par contre, c'est ccache qui ne marche plus : systématiquement chaque compil part en erreur dans ccache et n'est donc pas cachée (et ça floode /var/tmp/ccache de fichiers .tmp...)

Et concernant les paquets que je disais ne pas compiler avec gcc-4 (gimp et netpbm), en retirant -ftree-vectorize, ça compile.

----------

## Darkael

Pour info pour ceux qui ont des problèmes avec -ftree-vectorize et certains packages: en utilisant /etc/portage/bashrc il est possible d'utiliser un truc similaire à /etc/portage/package.use pour ajouter (ou retirer) des CFLAGS par package. Voyez ici pour des exemples. J'avais écrit une petite version qui supporte le versioning, mais je l'ai perdu lors d'une réinstallation  :Sad:  Je compte la refaire, je peux la poster si ça intéresse des gens.

Sinon, il doit être possible aussi de spécifier une version de gcc par package de la même façon, mais je sais pas si ça en vaut la peine.

----------

## kopp

J'en profite pour communiquer ce qui est dans la GWN. La semaine dernière, on nous disait qu'il n'était pas nécessaire de suivre le guide de mise à jour si l'on venait d'une version 3.4 mais cette semaine, on nous dit que 'ben que si, il faut'

Donc attention, préparer vous au emerge -e world  :Smile: Last edited by kopp on Wed May 31, 2006 1:25 pm; edited 1 time in total

----------

## nemo13

Dans la série à chacun son quota de bizarrerie :

 A priori chez-moi-çà-marche avec gcc 4.1 ( normal j'ai pas encore utilisé les vectorisations   :Rolling Eyes:  )

par contre j'ai gettext ( quelque soit la version ) qui plante systèmatiquement avec confcache donc , je détourne lachement ce post pour vous demandez ( aux gcc-4.1 power users ) si cela vous fait la même chose.

( je n'ai pas eu le courage d'essayer confcache avec gcc-3.4 )

A+:jlp

----------

## Anthyme

personne n'as d idée pour mon prelink ?

----------

## razer

je dois être plus chanceux que vous, car après une mise à jour de gcc en 4.1, et avec les flags :

```
CFLAGS="-march=pentium4 -mtune=pentium4 -Os -pipe -fomit-frame-pointer -ftree-vectorize"

CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -Bdirect"
```

Mon emerge -e world se passe bien jusqu'à maintenant (env. 400 paquets sur 480), mise à part fontconfig que j'ai dû recompiler sans le ftree-vectorize, et tous les paquets provenant de freedesktop.org dont le lien ne répond pas ce matin

Je n'ai pas encore essayé prelink, mais pour le reste tout semble rouler. Pas non plus de retour concernant le gain de performances, mon PC étant encore en train de compiler je ne peux pas juger

----------

## theniaky

Juste une petite question de noob   :Rolling Eyes:  :

J'utilise un bon vieux GCC 3.3.6... Quel est l'intérêt de passer à la 4.4.1 ? Je sais que les nouveau noyaux sont "optimisés" GCC 4, mais qu'est ce que ça change concrètement ? Le résultat est plus rapide ?

----------

## netfab

Et bien déjà, sans parler de performances ou d'optimisation, çà peut aider à résoudre des erreurs de compilation incompréhensibles  :Wink: 

----------

## guilc

 *theniaky wrote:*   

> Juste une petite question de noob   :
> 
> J'utilise un bon vieux GCC 3.3.6... Quel est l'intérêt de passer à la 4.4.1 ? Je sais que les nouveau noyaux sont "optimisés" GCC 4, mais qu'est ce que ça change concrètement ? Le résultat est plus rapide ?

 

Bah dans ce cas la, on serait encore tous à gcc-2.95  :Laughing: 

Plus sérieusement : outre le fait que les compils sont plus rapides, les optimisations meilleures, les nouveaux gcc gèrent plus d'extensions ISO C99 par exemple.

----------

## razer

 *razer wrote:*   

> je dois être plus chanceux que vous, car après une mise à jour de gcc en 4.1, et avec les flags :
> 
> ```
> CFLAGS="-march=pentium4 -mtune=pentium4 -Os -pipe -fomit-frame-pointer -ftree-vectorize"
> 
> ...

 

Bon... J'ai parlé un peu vite. Globalement je n'ai plus rien qui marche, tout du moins au niveau backend -> Gnome

Je ne sais pas si cela vient du ftree-vectorize ou ou du Bdirect, je relance mon -e system sans ces flags, mon proco va adorer... Cà m'apprendra à jouer le geek   :Embarassed: 

----------

## Anthyme

moi tout est passé sans probleme mais c'est surement parceque je n ai pas -fomit-frame-pointer ni -ftree-vectorize... Ca apporte beaucoup de choses ? (a part des problemes ?)

----------

## galerkin

De mon coté dans mon make.conf, je n'ai aucune ligne commencant par LDFLAGS="-Wl,-O1 -Wl...

Est ce vraiment utile et est-ce que ca apporte un réel gain? 

pour info je suis sous GCC 4.1.1(mais sans ftree-vectorize)   :Wink: 

Mes CFLAGS sont les suivants :  CFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe -frename-registers -fweb"

 pour amd 64 3000+

Avec ces flags, seuls 2 de mes 1000 paquets n'ont pas compilés   :Smile: 

nota : faut vraiment que je fasse le ménage ca fait très long à emerger...

----------

## yoyo

Bon, je profite du thread pour poser quelques question sur ce gcc-4.1 :

- 1 : le fameux -ftree-vectorize en quoi est-il utile ? Pour la compilation (temps de compil) ou pour les binaires générés ? Et quelles sont les conditions pour qu'il fonctionne (au niveau des sources/du système) ?

- 2 : je viens de voir un useflag : kdehiddenvisibility - Makes KDE symbols hidden by default, requires GCC 4.1 (experimental). L'avez-vous testé / savez-vous à quoi il correspond ?

Enjoy !

----------

## kopp

Pour ftree-vectorize je te renvois au manuel GCC, très éloquant  :Smile: 

```
-ftree-vectorize

    Perform loop vectorization on trees. 
```

Utile n'est ce pas ?

Sinon, je crois que pour le moment ça reste surtout une grosse source d'ennui, mais comme c'est une des nouvelles features de gcc4, tout le monde essaye .... pour l'enlever quelques heures plus tard  :Wink: 

Pour kde, parait que cette page explique le principe de visibility : http://gcc.gnu.org/wiki/Visibility

Récupérée d'après cette discussion

----------

## guilc

 *yoyo wrote:*   

> - 1 : le fameux -ftree-vectorize en quoi est-il utile ? Pour la compilation (temps de compil) ou pour les binaires générés ? Et quelles sont les conditions pour qu'il fonctionne (au niveau des sources/du système) ?

 

Pour ça, je te renvoie a la lecture de ce papier : http://gcc.gnu.org/projects/tree-ssa/vectorization.html

Ca sera plus compréhensible que si c'est moi qui explique   :Laughing: 

 *yoyo wrote:*   

> - 2 : je viens de voir un useflag : kdehiddenvisibility - Makes KDE symbols hidden by default, requires GCC 4.1 (experimental). L'avez-vous testé / savez-vous à quoi il correspond ?

 

Testé chez moi, ça marche sans problème, maintenant, en terme de gain, difficilement mesurable, c'est pas évident...

----------

## razer

Concernant la vélocité du compilateur g++ de cette version, je me suis lancé dans une compilation d'openoffice (la mienne datait un peu et la version binaire a des bugs chez moi), j'en suis à 9H de compil sur un P4 2.8 HT, et çà bourrine encore. Record de longueur battu, dernière compil avec gcc-4.0 = 8 heures et brouettes (6 heures avec gcc3.4).

Je ne sais pas si la compil d'Ooo peut faire office de référence, mais si tel est le cas c'est pas brillant   :Confused: 

----------

## yoyo

Merci pour vos liens et vos réponses.   :Very Happy: 

Enjoy !

----------

## guilc

 *razer wrote:*   

> Concernant la vélocité du compilateur g++ de cette version, je me suis lancé dans une compilation d'openoffice (la mienne datait un peu et la version binaire a des bugs chez moi), j'en suis à 9H de compil sur un P4 2.8 HT, et çà bourrine encore. Record de longueur battu, dernière compil avec gcc-4.0 = 8 heures et brouettes (6 heures avec gcc3.4).
> 
> Je ne sais pas si la compil d'Ooo peut faire office de référence, mais si tel est le cas c'est pas brillant  

 

Bizarre ça ! J'ai refais la compil d'OOo cet aprem (le seul truc que j'avais pas recompilé   :Laughing:  ) sur ma machine : P4B 2.8GHz (ceux a FSB533 sans HT) et 1Go de Ram, donc sensiblement équivalent a ta config, ça me donne ça :

```
     Fri Apr 21 16:05:09 2006 >>> app-office/openoffice-2.0.2-r2

       merge time: 6 hours, 2 minutes and 38 seconds.

     Wed May 31 22:46:39 2006 >>> app-office/openoffice-2.0.2-r2

       merge time: 6 hours, 3 minutes and 8 seconds.
```

La compil du 21 avirl c'est gcc 3.4.6, et celle du 31 mai, c'est gcc 4.1.1.

Même cflags dans les deux cas. J'ai pas du tout de différnce sur ce paquet !

Alors que si je prends un paquet comme les coreutils, c'est plutot mieux avec le 4.1.1 :

```
     Tue May 23 08:29:34 2006 >>> sys-apps/coreutils-5.96

       merge time: 6 minutes and 23 seconds.

     Sun May 28 10:54:22 2006 >>> sys-apps/coreutils-5.96

       merge time: 3 minutes and 53 seconds.
```

----------

## geekounet

Et sur mon laptop qui est moins puissant (voir ma signature) :

```
# genlop -t openoffice

 * app-office/openoffice

     Thu May 11 14:28:47 2006 >>> app-office/openoffice-2.0.2-r2

       merge time: 7 hours, 36 minutes and 15 seconds.
```

Et j'ai GCC 4.1 depuis le début de mon install.

Tu devais avoir un truc qui tournait en même temps  :Razz: 

----------

## razer

 *guilc wrote:*   

> 
> 
> Bizarre ça ! J'ai refais la compil d'OOo cet aprem (le seul truc que j'avais pas recompilé   ) sur ma machine : P4B 2.8GHz (ceux a FSB533 sans HT) et 1Go de Ram, donc sensiblement équivalent a ta config

 

Sauf que au vu de la manière dont se comportaient les sondes de gkrellm, le paramètre "-j" doit être filtré pour Ooo, car je n'avait pas plus d'un proco utilisé en même temps, dont c'est pas étonnant que cela soit plus rapide sans HT.

De plus, j'avais commenté les LDFLAGS pour être sûr que la compil ne me lâche pas au milieu...

Je me répère : au vu du filtrage effectué par Ooo sur les optimisations, je ne suis pas sûr que cela soit la meilleure référence pour juger...

Au bout du compte : 9 Heures de compilation, sans que le PC ne soit spécialement sollicité par ailleurs.

Enfin, au moins, Ooo s'est compilé normalement et fonctionne bien, là est l'essentiel

----------

## _Seth_

Comme on parle d'optimisation, est ce que vous connaissez The Language Shoutout Benchmark. Ce qui est dommage c'est que c'est le gcc version 3.3.5-20050130 qui est utilisé pour les benchmarks... J'ai hésité à poster le lien du coup, mais ça peut être intéressant pour faire la comparaison entre gcc-3.3.5 et le 4.1  :Wink: 

----------

## Tom_

Bonjour, moi j'ai des soucis avec Mono et les progs qui en dépendent. Mono compile mais gtk-sharp ou alors dbus ne compilent pas : 

Pour gtk-sharp :

```

/usr/bin/mcs -define:GTK_SHARP_2_6 -define:GTK_SHARP_2_8 -nowarn:0169,0612,0618 -out:glib-sharp.dll -target:library  ./Argv.cs ./Boxed.cs ./CDeclCallbackAttribute.cs ./ClassInitializerAttribute.cs ./ConnectBeforeAttribute.cs ./DefaultSignalHandlerAttribute.cs ./DelegateWrapper.cs ./DestroyNotify.cs ./EnumWrapper.cs ./FileUtils.cs ./GException.cs ./GString.cs ./GType.cs ./GTypeAttribute.cs ./Idle.cs ./IWrapper.cs ./ListBase.cs ./List.cs ./Log.cs ./MainContext.cs ./MainLoop.cs ./ManagedValue.cs ./Markup.cs ./Marshaller.cs ./MissingIntPtrCtorException.cs ./NotifyHandler.cs ./Object.cs ./ObjectManager.cs ./Opaque.cs ./PropertyAttribute.cs ./Signal.cs ./SignalArgs.cs ./SignalAttribute.cs ./SignalCallback.cs ./SList.cs ./Source.cs ./Thread.cs ./Timeout.cs ./TypeConverter.cs ./TypeFundamentals.cs ./UnwrappedObject.cs ./ValueArray.cs ./Value.cs ./WeakObject.cs AssemblyInfo.cs

error CS1548: Error during assembly signing. The specified file `gtk-sharp.snk' does not have a private key

Compilation failed: 1 error(s), 0 warnings

make[3]: *** [glib-sharp.dll] Erreur 1

make[3]: Leaving directory `/var/tmp/portage/gtk-sharp-2.8.2/work/gtk-sharp-2.8.2/glib'

make[2]: *** [all-recursive] Erreur 1

make[2]: Leaving directory `/var/tmp/portage/gtk-sharp-2.8.2/work/gtk-sharp-2.8.2/glib'

make[1]: *** [all-recursive] Erreur 1

make[1]: Leaving directory `/var/tmp/portage/gtk-sharp-2.8.2/work/gtk-sharp-2.8.2'

make: *** [all] Erreur 2

!!! ERROR: dev-dotnet/gtk-sharp-2.8.2 failed.

Call stack:

  ebuild.sh, line 1531:   Called dyn_compile

  ebuild.sh, line 931:   Called src_compile

  gtk-sharp-2.8.2.ebuild, line 60:   Called die

!!! (no error message)

!!! If you need support, post the topmost build error, and the call stack if relevant.

```

Pour Dbus : 

```
Making all in mono

make[2]: Entering directory `/var/tmp/portage/dbus-0.60-r4/work/dbus-0.60/mono'

Making all in .

make[3]: Entering directory `/var/tmp/portage/dbus-0.60-r4/work/dbus-0.60/mono'

/usr/bin/mcs --debug --unsafe --target library -o dbus-sharp.dll ./Arguments.cs ./Bus.cs ./BusDriver.cs ./Connection.cs ./DBusException.cs ./Error.cs ./ErrorMessage.cs ./Handler.cs ./InterfaceAttribute.cs ./InterfaceProxy.cs ./Introspector.cs ./Message.cs ./MethodAttribute.cs ./MethodCall.cs ./MethodReturn.cs ./ProxyBuilder.cs ./Server.cs ./Service.cs ./Signal.cs ./SignalAttribute.cs ./DBusType/IDBusType.cs ./DBusType/Array.cs ./DBusType/Boolean.cs ./DBusType/Byte.cs ./DBusType/Double.cs ./DBusType/Int16.cs ./DBusType/Int32.cs ./DBusType/Int64.cs ./DBusType/ObjectPath.cs ./DBusType/String.cs ./DBusType/UInt16.cs ./DBusType/UInt32.cs ./DBusType/UInt64.cs AssemblyInfo.cs

warning CS8029: Compatibility: Use -debug option instead of -g or --debug

warning CS8029: Compatibility: Use -unsafe instead of --unsafe

warning CS8029: Compatibility: Use -target:KIND instead of --target KIND

warning CS8029: Compatibility: Use -out:FILE instead of --output FILE or -o FILE

error CS1548: Error during assembly signing. The specified file `./dbus-sharp.snk' does not have a private key

Compilation failed: 1 error(s), 4 warnings

make[3]: *** [dbus-sharp.dll] Erreur 1

make[3]: Leaving directory `/var/tmp/portage/dbus-0.60-r4/work/dbus-0.60/mono'

make[2]: *** [all-recursive] Erreur 1

make[2]: Leaving directory `/var/tmp/portage/dbus-0.60-r4/work/dbus-0.60/mono'

make[1]: *** [all-recursive] Erreur 1

make[1]: Leaving directory `/var/tmp/portage/dbus-0.60-r4/work/dbus-0.60'

make: *** [all] Erreur 2

!!! ERROR: sys-apps/dbus-0.60-r4 failed.

Call stack:

  ebuild.sh, line 1531:   Called dyn_compile

  ebuild.sh, line 931:   Called src_compile

  dbus-0.60-r4.ebuild, line 111:   Called die

!!! make failed

!!! If you need support, post the topmost build error, and the call stack if relevant

```

J'ai fais quelques recherches mais j'ai rien trouvé. :/ Si quelqu'un a une idée, ca m'aiderait beaucoup.

```
emerge --info

Portage 2.1_rc3-r2 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.3.6-r3, 2.6.16-gentoo-r7 x86_64)

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

System uname: 2.6.16-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3500+

Gentoo Base System version 1.6.14

dev-lang/python:     2.4.2

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

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.1-r2

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-O2 -pipe -march=k8"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -pipe -march=k8"

DISTDIR="/usr/portage/distfiles"

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

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

LC_ALL="fr_FR@euro"

LINGUAS="fr fr_FR"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/xgl-coffee"

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

USE="amd64 X a52 aac alsa apache2 arts avi berkdb bitmap-fonts browserplugin cairo cli crypt cups dri dvb dvd dvdr dvdread eds emboss encode ffmpeg flac foomaticdb fortran gif glitz gpm gstreamer gtk2 hal imlib ipv6 isdnlog jpeg kde kdeenablefinal kdehiddenvisibility lirc lzw lzw-tiff mad matroska mono mozilla mp3 mp4 mpeg mpeg2 mplayer musepack musicbrainz ncurses nls nptl nptlonly nsplugin nvidia ogg opengl pam pcre pdf pdflib perl png pppd python qt quicktime readline reflection samba sdl session spell spl ssl tcpd tiff truetype-fonts type1-fonts usb v4l v4l2 vcd vorbis xcomposite xorg xpm xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_fr linguas_fr_FR userland_GNU video_cards_nvidia"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```

Merci.

----------

## _Seth_

 *Quote:*   

> J'ai fais quelques recherches mais j'ai rien trouvé. :/ Si quelqu'un a une idée, ca m'aiderait beaucoup.
> 
> 

 

J'ai jeté un coup d'oeil sur le net. C'est juste une idée comme ça mais essaye de synchroniser ton arbre de portage, il y a peut être une erreur dans la gestion des versions...

----------

## titoucha

 *Quote:*   

> error CS1548: Error during assembly signing. The specified file `gtk-sharp.snk' does not have a private key 

 

Il a un problème avec une clé de signature, essayes d'enlever "strict dans les FEATURES.

Au fait c'est quoi cette options "sfperms" dans ces FEATURES, je n'ai pas trouvé la définition.Last edited by titoucha on Fri Jun 02, 2006 4:25 pm; edited 1 time in total

----------

## mornik

Perso le passage de gcc 3.4 à 4.1 est mitigé. Certaines applis mettent plus de temps comme gcc ou glibc qui prennent en gros 1/2 heures dans les dents.

donc passage de 3h30 à 4h10 pour gcc, par exemple.

J'ai pas changé mes optimisations, et j'ai un athlon xp 2000+ avec 1go de ram.

Sinon chez moi tout est passé correctement.

----------

## truc

salut:)

j'ai également fait mon passage il y a quelque temps, et j'avais entendu dire que gcc-4 diminuait les temps de compilation.. Je ne comprends toujours pas comment c'est possible mais j'ai pu le constater, c'est époustouflant sur certains packages, par exemple:

```
Mon May 15 09:40:26 2006 >>> sys-libs/glibc-2.4-r3

       merge time: 1 hour, 28 minutes and 7 seconds.

Thu Jun  1 09:11:26 2006 >>> sys-libs/glibc-2.4-r3

       merge time: 38 minutes and 28 seconds.

```

bref y'en a d'autres.. mais, là ou j'ai été vraiment époustouflé c'était pour openoffice, je me souviens qu'en compilant openoffice, ça avait mis un peu plus de sept heure.. et là:

```
Sat Jun  3 13:59:52 2006 >>> app-office/openoffice-2.0.2-r2

       merge time: 3 hours, 19 minutes and 33 seconds.

```

Là je suis vraiment impressionné! Tout le monde ne semble pas avoir ces bons retours c'est bizarre.. Je précise que je n'ai pas de cflag particulier, et je n'ai rien fait de spécial(sans compter l'utilisation du pc en meme temps, matage de vidéos etc..) :O.

----------

## kaworu

Hello à tous !

migration sans problèmes ici, ( pas de changement de CFLAGS )

certaines applis compilent plus vite ( par ex. openoffice ) et d'autres plus lentement, dans l'absolu pas bcp de différence.

je vais attendre un peu pour la vectorisation... dommage.

----------

## netfab

Même chose pour moi : j'ai l'impression que les temps de compilation sont interminables :

 *Quote:*   

>      Sun May 21 16:36:57 2006 >>> www-client/mozilla-firefox-1.5.0.3
> 
>        merge time: 55 minutes and 49 seconds.
> 
>      Sat Jun  3 02:17:13 2006 >>> www-client/mozilla-firefox-1.5.0.3
> ...

 

En rouge, gcc 3.4.X, en bleu, gcc 4.1.1. Hallucinant  :Shocked: 

Je n'ai pas encore essayé openoffice, rafistolages d'après passage à ~x86 oblige.

----------

## netfab

çà va, çà s'améliore :

 *Quote:*   

> 
> 
> Sat Jun  3 02:17:13 2006 >>> www-client/mozilla-firefox-1.5.0.3
> 
>        merge time: 1 hour, 47 minutes and 35 seconds.
> ...

 

La différence entre rouge et bleu ? j'ai désactivé le ccache  :Confused: 

----------

## Pixys

Je profite de ce post (je ne sais pas si mon intervention mérite un nouveau post) car j'ai une interrogation concernant cette doc: Guide de mise a jour de GCC pour Linux Gentoo notamment ce qui concerne la désinstallation des anciennes versions de gcc.

Lors de l'installation de gcc-4.1.1 (par exemple) sur une nouvelle installe, ils disent de faire:

```
# emerge -aC "<sys-devel/gcc-VOTRE-NOUVELLE-VERSION-DE-GCC"
```

ce qui, d'après mes maigres connaissances va désinstaller le gcc nouvellement installé... non? De plus cela va en contradiction avec:

 *Quote:*   

> On peut désormais supprimer l'ancienne version de GCC sans le moindre risque. Si vous en sentez le besoin, vous pouvez lancer la commande suivante (comme d'habitude, remplacez =sys-devel/gcc-3.3* par la version que vous voulez désinstaller) :
> 
> Exemple de code 2.3 : Désinstallation des anciennes versions de GCC
> 
> ```
> ...

 

Alors soit c'est moi, soit c'est la doc qui est bancale....

Personnellement j'ai installé gcc-4.1.1  à partir d'un gcc-3.4.4 et impossible de désinstaller ce dernier ("il" pretend ne pas trouver la package) pourquoi?

----------

## sireyessire

 *Pixys wrote:*   

> Je profite de ce post (je ne sais pas si mon intervention mérite un nouveau post) car j'ai une interrogation concernant cette doc: Guide de mise a jour de GCC pour Linux Gentoo notamment ce qui concerne la désinstallation des anciennes versions de gcc.
> 
> Lors de l'installation de gcc-4.1.1 (par exemple) sur une nouvelle installe, ils disent de faire:
> 
> ```
> ...

 

sans vouloir être méchant, c'est toi  :Wink: 

il y a un < ce qui pour un matheux comme moi à un sens très précis: strictement inférieur. Par conséquent le # emerge -aC "<sys-devel/gcc-VOTRE-NOUVELLE-VERSION-DE-GCC" signifie désinstaller toute version strictement antérieure à la celle que tu viens d'installer, bref ça ne t'enlevera pas celle que tu viens d'installer.

sinon juste pour info, gcc-4.1.1 est en stable pour les ppc (c'était les seuls hier soir à être passer en stable)

[edit] orthographe

----------

## geekounet

 *sireyessire wrote:*   

> sinon juste pour info, gcc-4.1.1 est en stable pour les ppc (c'était les seuls hier soir à être passer en stable)

 

Et sera stabilisé sur toutes les archs pour la 2006.1  :Smile: 

----------

## Pixys

 *sireyessire wrote:*   

>  *Pixys wrote:*   Je profite de ce post (je ne sais pas si mon intervention mérite un nouveau post) car j'ai une interrogation concernant cette doc: Guide de mise a jour de GCC pour Linux Gentoo notamment ce qui concerne la désinstallation des anciennes versions de gcc.
> 
> Lors de l'installation de gcc-4.1.1 (par exemple) sur une nouvelle installe, ils disent de faire:
> 
> ```
> ...

 

Ok looool pas de problème  :Smile: 

je suis un très mauvais matheux (j'avoue que c'est un handicape, les maths sont un outil puissant!)

c'est pour ça que je fais de la physique et de la mécanique.... 

merci d'avoir éclairer ma chandelle.

----------

## Temet

Vous allez me prendre pour un barge mais j'ai remarqué que je compilais plus vite si je balançais la compilation dans un tty (je repars sous KDE pendant que ça compile) ...

J'ai essayé de me convaincre que l'affichage des 3 millions de lignes à chaque compilation était plus rapide dans un tty que dans un xterm ... va comprendre Charles.

----------

## geekounet

 *Temet wrote:*   

> Vous allez me prendre pour un barge mais j'ai remarqué que je compilais plus vite si je balançais la compilation dans un tty (je repars sous KDE pendant que ça compile) ...
> 
> J'ai essayé de me convaincre que l'affichage des 3 millions de lignes à chaque compilation était plus rapide dans un tty que dans un xterm ... va comprendre Charles.

 

Tu peux aussi lancer ton emerge dans un screen et le détacher, comme ça pas du tout d'affichage  :Smile: 

----------

## Temet

Et t'as vu une diff au niveau du temps de compilation??

----------

## _Seth_

J'ai pas encore essayé mais peut être avez-vous déjà utilisé emerge avec l'option -q (quiet) ? Est ce que cela réduit le temps de compil ? Il me semble avoir lu sur le forum que les outputs en python sont pas très rapide donc qu'un emerge silencieux gagne pas mal en vitesse. Evidement, s'il y a un paquet qui plante, on a pas beaucoup d'infos du coup   :Sad: 

----------

## geekounet

 *Temet wrote:*   

> Et t'as vu une diff au niveau du temps de compilation??

 

J'ai pas vraiment vérifié, et je le fais pas souvent, seulement quand je lancais mes updates depuis mon iut  :Smile: 

----------

## tnntwister

ben ca me donne ca...

```
Couldnt get a file descriptor referring to the console
```

(non pas du tout decourage  :Wink: )

----------

## kopp

 *tnntwister wrote:*   

> ben ca me donne ca...
> 
> ```
> Couldnt get a file descriptor referring to the console
> ```
> ...

 

Tu parles de quoi ?

Sinon, bravo les maths hein. C'est vrai que la rigeur en physique, ça choque du monde. Tiens une intégrale triple sur un espace non borné... bon, l'intégrale donne un résultat probable : elle était calculable ! Argh

Sinon, pour l'histoire tty/terminal (xterm, gnome-terminal, konsole, autre) j'avais déjà remarqué la chose.

Je pense qu'effectivement,  les tty sont plus rapides pour afficher le texte. Et je suis d'accord sur le fait que la sortie de texte ralentit la compilation !

----------

## _Seth_

CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -finline-functions -finline-functions-called-once -fivopts -ftree-vectorize -ftracer"[/code]

et openoffice n'est pas passé avec ces cflags. Par contre j'ai remarqué une diminution du temps de compil :

 *genlop wrote:*   

>      Mon May 15 20:12:48 2006 >>> app-office/openoffice-2.0.2-r2
> 
>  merge time: 8 hours, 57 minutes and 35 seconds.
> 
>      Fri Jul  7 13:09:31 2006 >>> app-office/openoffice-2.0.3
> ...

 

avec rouge = gcc-3.6.X et bleu = gcc-4.1.1

Je n'ai rencontré qu'un problème pour l'instant et je me demande si ce n'est pas à cause du kdehiddenvisibility (j'ai activé ce useflag pour passer à kde-3.5.3: kdemultimedia ne veut plus compiler car un appel d'une librairie de kdelibs ne passe pas...J'a désactivé le ccache et changé mes Cflags en

[code]

 *emerge kde-base/kdemultimedia-3.5.3-r1failed wrote:*   

> /usr/kde/3.5/lib/libkhtml.so: undefined reference to `__cxa_get_exception_ptr@CXXABI_1.3.1'

 

[code]equery belongs /usr/kde/3.5/lib/libkhtml.so

kde-base/kdelibs-3.5.3-r3 (/usr/kde/3.5/lib/libkhtml.so -> libkhtml.so.4.2.0)[/code]

Sinon dans l'ensemble, je suis plutôt satisfait de gcc-4.1  :Wink: 

----------

## mornik

 *_Seth_ wrote:*   

> J'ai pas encore essayé mais peut être avez-vous déjà utilisé emerge avec l'option -q (quiet) ? Est ce que cela réduit le temps de compil ? Il me semble avoir lu sur le forum que les outputs en python sont pas très rapide donc qu'un emerge silencieux gagne pas mal en vitesse. Evidement, s'il y a un paquet qui plante, on a pas beaucoup d'infos du coup  

 

Dans ce cas il reste les logs. Je vais tester ce soir pour voir.

----------

## blasserre

 *kopp wrote:*   

> Effectivement le ftree-vectorize pose quelques problèmes. fontconfig par exemple : ça faisait planter firefox et thunderbird (qui n'avaient pas encore été recompilés eux par contre)
> 
> Ensuite, zlib faisait planter encore thunderbird sur quelques mails
> 
> Et puis openssl faisait planter OpenOffice 2 pour la demande de lecture de licence etc au premier lancement.
> ...

 

bon je sais pas trop ou poster ça

vous pouvez ajouter app-text/poppler-0.5.3  à la liste des paquets qui posent problème avec ce flag

----------

## man in the hill

Tout ça pour l'arch  x86 car j'ai recompilé ma tour amd64 avec cette flag et aucun soucis avec aucun paquets !!!!

Petit extrait :

_-_ fontconfig

```

make[2]: entrant dans le répertoire « /var/tmp/portage/fontconfig-2.3.2-r1/work/fontconfig-2.3.2/fc-match »

if x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes    -Wmissing-prototypes -Wmissing-declarations    -Wnested-externs -fno-strict-aliasing    -march=k8 -O2 -msse3 -pipe -ftree-vectorize -MT fc-match.o -MD -MP -MF ".deps/fc-match.Tpo" \

     -c -o fc-match.o `test -f 'fc-match.c' || echo './'`fc-match.c; \

   then mv -f ".deps/fc-match.Tpo" ".deps/fc-match.Po"; \

   else rm -f ".deps/fc-match.Tpo"; exit 1; \

   fi

```

```

 * Creating font cache...

>>> Regenerating /etc/ld.so.cache...

>>> media-libs/fontconfig-2.3.2-r1 merged.

>>> Recording media-libs/fontconfig in "world" favorites file...

>>> No packages selected for removal by clean.

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 8 config files in /etc need updating.

 * Type emerge --help config to learn how to update config files.
```

poppler

```

x86_64-pc-linux-gnu-g++ -Wall -Wno-unused -march=k8 -O2 -msse3 -pipe -ftree-vectorize -o .libs/pdftoppm pdftoppm.o parseargs.o  ../poppler/.libs/libpoppler.so /usr/lib64/libjpeg.so /usr/lib64/libfontconfig.so /usr/lib64/libfreetype.so -lz /usr/lib64/libexpat.so

```

```
>>> Regenerating /etc/ld.so.cache...

>>> Original instance of package unmerged safely.

 * You need to rebuild everything depending on poppler, use revdep-rebuild

>>> Regenerating /etc/ld.so.cache...

>>> app-text/poppler-0.5.3 merged.

>>> Recording app-text/poppler in "world" favorites file...

>>> No packages selected for removal by clean.

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 8 config files in /etc need updating.

 * Type emerge --help config to learn how to update config files.
```

Donc tout ces problèmes sont spécifiques aux apps 32 bit ...et non 64 bit !..

```

crazy_gentoo  %

 emerge --info

Portage 2.1.1 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r7 x86_64)

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

System uname: 2.6.17-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+

Gentoo Base System version 1.12.4

Last Sync: Sun, 10 Sep 2006 15:20:01 +0000

ccache version 2.4 [enabled]

app-admin/eselect-compiler: [Not Present]

dev-lang/python:     2.3.5, 2.4.3-r3

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     2.4-r2

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.18.1

sys-devel/autoconf:  2.13, 2.60

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

sys-devel/binutils:  2.17

sys-devel/gcc-config: 1.3.13-r3

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.16

ACCEPT_KEYWORDS="amd64 ~amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=k8 -O2 -msse3 -pipe -ftree-vectorize"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

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

CXXFLAGS="-march=k8 -O2 -msse3 -pipe -ftree-vectorize"

DISTDIR="/usr/portage/distfiles"

EMERGE_DEFAULT_OPTS="--alphabetical"

FEATURES="assume-digests autoconfig ccache digest distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://adelie.polymtl.ca/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://gentoo.seren.com/gentoo ftp://gentoo.chem.wisc.edu/gentoo/"

LANG="fr_FR@euro"

LC_ALL="fr_FR@euro"

LINGUAS="fr fr_FR"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/overlays/xgl-coffee /usr/local/overlays/faya-gentoo /usr/local/overlays/gkrellm-overlay"

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

USE="amd64 X a52 aac aalib acpi aim alsa avi bash-completion berkdb bidi bitmap-fonts bluetooth bonobo bzip2 cairo caps cdda cdinstall cdio cdparanoia cdr clamav cli crypt cscope cups dbus dio dlloader dri dts dv dvd dvdr dvdread eds elibc_glibc emboss emul-linux-x86 encode esd ethereal examples fam fbsplash ffmpeg firefox flac fortran freetype ftp gb gdbm gif glitz gnome gnutls gphoto2 gpm gstreamer gtk gtk2 hal howl iconv imagemagick input_devices_keyboard input_devices_mouse ipv6 isdnlog jabber javascript joystick jpeg kernel_linux lcms ldap libcaca libg++ linguas_fr linguas_fr_FR live lm_sensors mad maildir matroska mikmod mime motif mp3 mpeg msn ncurses nls nptl nptlonly ogg oggvorbis opengl oss pam pcre pdflib perl png ppds pppd prelude python qt qt3 qt4 quicktime readline reflection ruby scanner sdl session sockets source spell spl ssl stream suspend2 svg tcltk tcpd theora threads truetype truetype-fonts type1-fonts udev unicode userland_GNU vcd video_cards_nvidia videos vlm vorbis wxwindows xine xml xmms xorg xv xvid zlib"

Unset:  CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```

----------

## GentooUser@Clubic

Ça compile mais es-ce que ça marche ?

avec -ftree-vectorize j'avais une erreur de segmentation dans libX11 au lacement de Azureus, et un plantage de konqueror/kpdf  a l'affichage des fichiers PDF.

J'ai recompilé mon world sans ce flag et tout remarche   :Very Happy:  3 emerge -e world en une semaine c'est EDF qui va être content   :Laughing: 

----------

## man in the hill

 *GentooUser@Clubic wrote:*   

> Ça compile mais es-ce que ça marche ?
> 
> avec -ftree-vectorize j'avais une erreur de segmentation dans libX11 au lacement de Azureus, et un plantage de konqueror/kpdf  a l'affichage des fichiers PDF.
> 
> J'ai recompilé mon world sans ce flag et tout remarche   3 emerge -e world en une semaine c'est EDF qui va être content  

 

Quand je lance azureus :

```
faya@crazy_gentoo ~ $

 azureus

using /home/faya/.azureus/gentoo.config

${UI_OPTIONS} is no longer supported. ${UI} should be used instead instead

Unsetting ${UI_OPTIONS}

DEBUG::Sun Sep 10 20:01:13 GMT 2006  Données manquantes /home/faya/Downloads/eclipse-SDK-3.2-linux-gtk-x86_64.tar.gz

Warning: Cannot convert string "-b&h-lucida-medium-r-normal-sans-*-140-*-*-p-*-iso8859-1" to type FontStruct

```

Pas de problème de segmentation  mais bon je n'ai pas encore de problème particulier sauf avec  par mon xgl qui a pri un bon coup sur la tête, je vais essayer de recompiler X sans cette  flag pour voir ...

Tu as de la chance qu' EDF ne t'a pas coupé le jus en plein emerge   :Laughing:  ... Je suis relativement soulé avec eux en martinique ...ou ils nous bien couilloné avec tout le soleil qui a pour faire de l'électricité ... mais bon ...

----------

## geekounet

 *blasserre wrote:*   

>  *kopp wrote:*   Effectivement le ftree-vectorize pose quelques problèmes. fontconfig par exemple : ça faisait planter firefox et thunderbird (qui n'avaient pas encore été recompilés eux par contre)
> 
> Ensuite, zlib faisait planter encore thunderbird sur quelques mails
> 
> Et puis openssl faisait planter OpenOffice 2 pour la demande de lecture de licence etc au premier lancement.
> ...

 

Et gnome-base/librsvg aussi qui me segfault toutes les applis Gnome qui utilisent du SVG.

Mais pour autant, pas besoin de désactiver complètement le flag, il suffit d'utiliser /etc/portage/env/  :Smile: 

----------

## blasserre

 *pierreg wrote:*   

> Mais pour autant, pas besoin de désactiver complètement le flag, il suffit d'utiliser /etc/portage/env/ 

 

+1

juste une précision au passage :

ces fichier étant lus par portage après le make.conf il penser à changer CXXFLAGS pout les applis C++

```
CFLAGS="${CFLAGS/-ftree-vectorize}"

CXXFLAGS="${CXXFLAGS/-ftree-vectorize}"
```

je suis sur que je suis en train de dire une grosse connerie mais bon....

----------

## GentooUser@Clubic

 *man in the hill wrote:*   

>  *GentooUser@Clubic wrote:*   Ça compile mais es-ce que ça marche ?
> 
> avec -ftree-vectorize j'avais une erreur de segmentation dans libX11 au lacement de Azureus, et un plantage de konqueror/kpdf  a l'affichage des fichiers PDF.
> 
> J'ai recompilé mon world sans ce flag et tout remarche   3 emerge -e world en une semaine c'est EDF qui va être content   
> ...

 

Bon ça dois venir de mon arch (x86) ou de ma combinaison de CFLAGS.

----------

## man in the hill

J'ai parlé trop vite   :Laughing:  , c'est bien cette flag qui m'avait ruiné mon Xgl   :Twisted Evil:  ! 

Toute façon l'optimisation extrème ce n'est trop mon truc et c'est une sacrée perte de temps ! ...  Ma becanne est assez réactive, il lui manque juste un dual core   :Razz:   .

----------

## titoucha

 *man in the hill wrote:*   

> J'ai parlé trop vite   , c'est bien cette flag qui m'avait ruiné mon Xgl   ! 
> 
> Toute façon l'optimisation extrème ce n'est trop mon truc et c'est une sacrée perte de temps ! ...  Ma becanne est assez réactive, il lui manque juste un dual core    .

 

Tu vas pas par quatre chemins pour la réactivité   :Wink: 

----------

## man in the hill

 *titoucha wrote:*   

>  *man in the hill wrote:*   J'ai parlé trop vite   , c'est bien cette flag qui m'avait ruiné mon Xgl   ! 
> 
> Toute façon l'optimisation extrème ce n'est trop mon truc et c'est une sacrée perte de temps ! ...  Ma becanne est assez réactive, il lui manque juste un dual core    . 
> 
> Tu vas pas par quatre chemins pour la réactivité  

 

J'en ai marre de ce jeu de dupe sur les flags qui revient comme un boomerang tous les 6 mois et j'ai vraiment perdu mon temps dans cette migration et l'époque est passé ou je pouvait supporter ça (je me suis meme retrouvé sans serveur X pendant une bonne heure !). De toute façon, je garde mes safe flags (+ les optmisations proposé par les dev du paquet)   et c'est sur que dans un futur proche, je vais me payer un dual core amd64 4800+ ... et Je vais privilégier un matos puissant qu'une surenchère de flags ...

                                                          @ +

----------

## titoucha

 *man in the hill wrote:*   

> 
> 
> J'en ai marre de ce jeu de dupe sur les flags qui revient comme un boomerang tous les 6 mois et j'ai vraiment perdu mon temps dans cette migration et l'époque est passé ou je pouvait supporter ça (je me suis meme retrouvé sans serveur X pendant une bonne heure !). De toute façon, je garde mes safe flags (+ les optmisations proposé par les dev du paquet)   et c'est sur que dans un futur proche, je vais me payer un dual core amd64 4800+ ... et Je vais privilégier un matos puissant qu'une surenchère de flags ...
> 
>       @ +

 

J'était plus ou moin d'accord avec toi, j'usquau moment ou j'ai testé les hash-styles et là j'ai vu une différence, donc je pense que dans la plupart des cas les flags de la mort-qui-tue c'est un peut l'arlesienne, mais de temps en temps tu en as un qui fait vraiment la différence.

Par contre je pense que pour l'instant c'est encore un peut trop "alpha".

PS: J'ai une machine puissante, et même là dessus j'ai vu la différence de fluidité.

----------

## loopx

 *Anthyme wrote:*   

> moi j ai lancé un script
> 
> ```
> emerge -e world
> 
> ...

 

mdr, j'y pensais justement, meme qu'a la fin, tu peux toujours rajouter un tit init 0  :Wink: 

----------

## nonas

Les problèmes avec -ftree-vectorize sont-ils toujours d'actualité ?

(J'vais essayé ce flag sur l'update de ce soir et je vous dirai)

```
[ebuild     U ] sys-fs/udev-100-r1 [100] USE="(-selinux)" 0 kB 

[ebuild     U ] x11-libs/libXfont-1.2.0-r2 [1.2.0-r1] USE="-debug -ipv6" 0 kB 

[ebuild     U ] x11-terms/xterm-220 [219] USE="truetype unicode -Xaw3d -paste64 -toolbar" 782 kB 

[ebuild     U ] media-libs/netpbm-10.35.0 [10.34] USE="jpeg png svga tiff xml zlib" 2,058 kB 

[ebuild     U ] dev-java/java-config-wrapper-0.12 [0.11] 7 kB 

[ebuild     U ] app-portage/eix-0.7.4 [0.7.3] USE="-sqlite%" 339 kB 

[ebuild     U ] media-sound/lame-3.97_beta3 [3.97_beta2] USE="gtk -debug" 1,296 kB 

[ebuild     U ] www-client/dillo-0.8.6 [0.8.5-r3] USE="nls ssl truetype -ipv6" 683 kB
```

----------

## Scullder

 *nonas wrote:*   

> Les problèmes avec -ftree-vectorize sont-ils toujours d'actualité ?

 

J'en ai jamais eu et j'ai fait un emerge -e world récemment.

----------

## GentooUser@Clubic

 *nonas wrote:*   

> Les problèmes avec -ftree-vectorize sont-ils toujours d'actualité ?
> 
> (J'vais essayé ce flag sur l'update de ce soir et je vous dirai)
> 
> 

 

Pour moi ils le sont (mes essais datent de la semaine dernière), mais ça semble beaucoup changer suivant les logiciels utilisés et les autres options de compilation.

----------

## nonas

 *Scullder wrote:*   

>  *nonas wrote:*   Les problèmes avec -ftree-vectorize sont-ils toujours d'actualité ? 
> 
> J'en ai jamais eu et j'ai fait un emerge -e world récemment.

 

 *GentooUser@Clubic wrote:*   

> Pour moi ils le sont (mes essais datent de la semaine dernière), mais ça semble beaucoup changer suivant les logiciels utilisés et les autres options de compilation.

 

OK. Merci pour les retours.

Bon là j'ai pas eu de problème non plus, tout compile bien, et apparement xterm et eix tournent normalement ausi.

Je vais pas tenter le emerge -e, j'essaierai de venir rendre compte au fur et à mesure  :Wink: 

Et si ça casse je saurai d'où ça peut venir ^^

emerge --info

----------

## titoucha

Si un ebuild ne passe pa tu as la possibilité en créant un fichier dans /etc/portage/env/app-portage/eix par exemple pour eix et de mettre dans ce fichier les CFLAGS, ou autre chose, qui vont bien.

----------

## nonas

Bon ça semble pas une bonne idée de mettre ce CFLAG pour udev, il a tout cassé les permissions. (PTY, soundcard etc...)

Du coup ben j'ai remis mes safe CFLAGS pour retrouver une machine qui tourne parfaitement comme avant  :Wink: 

J'ai pas vraiment envie de devoir tester chaque truc pour régler les CFLAGS par paquet, et j'ai pas trop envie de risquer le cassage du système à chaque update.

----------

## blasserre

 *nonas wrote:*   

> Bon ça semble pas une bonne idée de mettre ce CFLAG pour udev, il a tout cassé les permissions. (PTY, soundcard etc...)

 

c'est bizarre, à priori tu est le seul, tu est sur de ton coup ?

tu as quelle version d'udev ?

----------

## nonas

En fait c'est possible que ce soit du à la version d'udev d'hier soir (100-r1), parce que la 100-r2 est apparu ce matin.

Si j'ai le courage je retesterai avec la nouvelle version d'udev pour être sûr mais ça ne change rien à mes conclusions.

----------

## man in the hill

 *nonas wrote:*   

> En fait c'est possible que ce soit du à la version d'udev d'hier soir (100-r1), parce que la 100-r2 est apparu ce matin.
> 
> Si j'ai le courage je retesterai avec la nouvelle version d'udev pour être sûr mais ça ne change rien à mes conclusions.

 

J'ai eu le même problème ave la 100-r1  et je suis revenu  à la 100 pour l'instant ...

----------

## nonas

En effet il semblerait que les problèmes étaient liés à la version 100-r1 de udev.

Avec la 100-r2 tout va bien jusque là.

----------

## kwenspc

Bon je viens de terminer la maj de mon pc avec xorg 7.0 et gcc4 (pc du taf).

Contrairement à mon laptop perso j'ai pas mal d'instabilité sous gnome, je pense que cela est dû en grosse partie par gtk+ et la glib qui n'ont pas été recompilé  :Laughing: 

Et peut-être aussi par des LDFLAGS un peut trop méchants. (j'ai bien mis -ftree-vectorize)

J'ai réduit un peu la dureté des LDFLAGS et hop un ptit emerge -e world  là je pense que tout devrait passer.

Sinon le gain de performance est visible. Gnome est nettement plus rapide, plus réactif que ce soit au chargement mais surtout à l'utilisation. 

Sous mon laptop c'est le jour et la nuit, en plus d'être stable (LDFLAGS plus gentil, mais CFLAGS beaucoup plus portés vers l'optimisation de la taille).

```

CFLAGS="-O3 -march=pentium4 -mtune=pentium4 -pipe -fomit-frame-pointer -mfpmath=sse,387 -mmmx -msse -ftree-vectorize"

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

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

```

Ceci dit je suis pas bien certains de la pertinence de mes LDFLAGS, j'ai pas trop cherché à voir si il y avait des options paradoxales ou redondantes...

----------

## ceric35

Je vient de finir mon "emerge -e world" avec -ftree-vectorize

et les packages libdvbpsi et samba n'ont pas compilés

pour samba c'etait une erreur de segmentation du compilateur

essayé plusieurs fois, mais sans succès...

Sinon, firefox marche plus, apparement parce que la

complation des plugins (mplayerplug-in...) le fait planter

```
firefox

No running windows found

/usr/libexec/mozilla-launcher: line 117: 22286 Erreur de segmentation  "$mozbin" "$@"

firefox-bin exited with non-zero status (139)
```

bref, je sais pas si toutes les erreurs viennent de ce flags

mais je vais pas le laisser je pense...

----------

## kernelsensei

il me semble que c'est fontconfig qui n'aime pas le vectorize...

----------

## Scullder

 *kernel_sensei wrote:*   

> il me semble que c'est fontconfig qui n'aime pas le vectorize...

 

J'ai compilé fontconfig 2.4.1 avec, et ça m'a tout l'air de fonctionner maintenant.

----------

## geekounet

 *Scullder wrote:*   

>  *kernel_sensei wrote:*   il me semble que c'est fontconfig qui n'aime pas le vectorize... 
> 
> J'ai compilé fontconfig 2.4.1 avec, et ça m'a tout l'air de fonctionner maintenant.

 

Tu est en quel arch ? Il me semble que ça fonctionne bien en amd64.

----------

## Scullder

 *pierreg wrote:*   

> Tu est en quel arch ? Il me semble que ça fonctionne bien en amd64.

 

Oui, je suis en ~amd64

----------

## blasserre

rooh la loose, ça marche plus en x86  :Crying or Very sad: 

sans le flag quelle que soit la version...

----------

## _Seth_

 *blasserre wrote:*   

> rooh la loose, ça marche plus en x86 
> 
> sans le flag quelle que soit la version...

 

 :Question:  étrange, je suis en ~x86 et :

```
# eix fontconfig

[I] media-libs/fontconfig

     Available versions:  (1.0)  2.2.2 2.2.3 2.3.2 2.3.2-r1 2.3.2-r2 2.4.1

     Installed:           2.4.1(1.0)

     Homepage:            http://fontconfig.org/

     Description:         A library for configuring and customizing font access
```

et mis a part pour certains paquets (assez peu) j'ai activés les cflags suivants :

```
CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -finline-functions -finline-functions-called-once -fivopts -ftree-vectorize -ftracer"
```

je ne me souviens pas avoir desactivé ces cflags pour fontconfig...

----------

## Longfield

perso j'ai eu une très mauvaise expérience ce week-end avec le fameux -ftree-vectorize.

Je suis aussi en ~x86, et comme tout le monde, firefox et thunderbird se vautrent (sûrement à cause de fontconfig).

Résultat: je l'ai viré, et je me refais un emerge -eav world ... 

J'ai pas envie de tweaker mes options de compilation pour les différents paquets. Dommage car je pense vraiment que c'est une option sympa pour vraiment tirer le maximum de nos procs, mais bon, on va attendre encore un peu.

----------

## ceric35

 *Scullder wrote:*   

>  *kernel_sensei wrote:*   il me semble que c'est fontconfig qui n'aime pas le vectorize... 
> 
> J'ai compilé fontconfig 2.4.1 avec, et ça m'a tout l'air de fonctionner maintenant.

 

exact, firefox se lance bien maintenant...

merci

----------

## blasserre

 *_Seth_ wrote:*   

>  étrange, je suis en ~x86 et :
> 
> ```
> # eix fontconfig
> 
> ...

 

 :Confused:  bah moi j'ai eu la délicate idée de passer en -03 ... il y a bien eu quelques recompiles de paquets entre temps mais j'utilise la bidouille du /etc/portage/env/*  donc je vois pas trop.. je jetterai un coup d'il plus poussé ce soir

edit : quotes

----------

## Nah

 *ceric35 wrote:*   

> 
> 
> Sinon, firefox marche plus, apparement parce que la
> 
> ...
> ...

 

Pareil, mais une simple recompilation de zlib avec C/CXX/LD/flags au minimun, à régler le problème chez moi.

Pour ma part, c'est dbus qui ma posé pas mal de problème, à part ça -ftree-vectorize  marche vraiment bien.  :Smile: 

----------

## ceric35

 *kizuna wrote:*   

>  *ceric35 wrote:*   
> 
> Sinon, firefox marche plus, apparement parce que la
> 
> ...
> ...

 

lol, bah en fait j'avais lancer un "emerge -e world" sans le -ftree-vectorize et je l'ai arreter pour tester la solution du fontconfig

mais comme zlib est le premier package chez moi, bah le resultat à été faussé...

c'etait donc zlib l'erreur, et pas fontconfig

par contre, l'erreur apparait encore lorsque je visite des sites genre : http://gentoo-wiki.com/TIP_The_/etc/portage/bashrc_file

EDIT : mplayerplug-in non plus n'aime pas -ftree-vectorize

----------

