# make.conf e features

## stifler83

Ciao ragazzi, volevo sapere se qualcuno era in grado di darmi una dritta sul mio make.conf nel merito cosa posso togliere o aggiungere e perchè   :Cool: 

Le FEATURES, FETCHCOMMAND e RESUMECOMMAND sonoi punti che più mi interessa migliorare.

```
ACCEPT_KEYWORDS="amd64"

FEATURES="${FEATURES} mini-manifest parallel-fetch userfetch buildpkg candy ccache fixlafiles parallel-install fail-clean getbinpkg news preserve-libs prelink-checksums distcc-pump collision-protect sandbox"

CHOST="x86_64-pc-linux-gnu"

CFLAGS="-mtune=native -march=native -O2 -pipe"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j5"

EMERGE_DEFAULT_OPTS="--ask --verbose --quiet"

PORTAGE_BINHOST=/usr/portage/packages

CCACHE_SIZE="5G"

CCACHE_DIR="/var/cache/ccache"

USE="acpi alsa /

bash-completion /

cracklib crypt cdr curl /

dvdr /

gnutls /

ithreads ipv6 /

libnotify lm_sensors /

ncurses networkmanager nsplugin /

posix policykit /

samba symlink ssl sse sse2 ssse3 sse3 sse4_1 /

threads /

udev upnp /

vim-syntax /

xinerama /

zsh-completion /

-ppp -qt4 -kde -gnome -gtk -doc -handbook -wicd"

LINGUAS="it"

INPUT_DEVICES="evdev"

VIDEO_CARDS="intel nvidia"

SYNC="git://github.com/funtoo/portage-mini-2010.git rsync://rsync3.fr.gentoo.org/gentoo-portage"

GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo/ http://gentoo.wheel.sk/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/"

APACHE2_MODULES="${APACHE2_MODULES} apache2_modules_auth_digest"

QEMU_SOFTMMU_TARGETS="arm i386 ppc ppc64 x86_64"

QEMU_USER_TARGETS="arm i386 ppc ppc64 x86_64"

ACCEPT_LICENSE="*"

PORTDIR_OVERLAY=/opt/my_overlay/

source /var/lib/layman/make.conf

FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P \${DISTDIR}/\${FILE} \${URI}"

RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P \${DISTDIR}/\${FILE} \${URI}"
```

----------

## ago

Io penso che ognuno le setta a secondo delle esigenze che ha; hai dato un occhio a:

```
man make.conf
```

?

----------

## stifler83

Bè mi pare il minimo che ho dato uno sguardo al man  :Very Happy: 

In ogni caso sono curioso di sapere se c'è qualcuno che sai darmi qualche indicazione o parere su quello che ho fatto, proprio come ho scritto sopra  :Wink: 

Ti ringrazio comunque dell'interessamento

----------

## darkmanPPT

Se vuoi puoi sputtanarti   :Laughing:   un po' il sistema con 

```
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,now -Wl,--hash-style=gnu"

```

scherzo, dai.

io ho questa riga in più. Cosa mi sia cambiato in termini prestazionali non lo so. -Wl,-01 è già attiva di default mi pare. le altre non penso.

Dicono che con --hash-style=gnu tu ottenga dei files più leggeri.

non so.

Se cerchi sul forum, troverai svariate e svariate discussioni in merito alle LDFLAGS.

In generale, come dice ago, ogniuno fa il tuning come vuole.

----------

## djinnZ

@stiffler83: oltre nel man guarda anche nel make.conf.example ma nello specifico, a parte le solite opzioni di dubbia utilità e di certamente scarsa civiltà, l'unica cosa che puoi fare è optare per un altro downloader (es. aget) per attivare il download multiplo o segmentato.

-mtune=native è ridondante (e -march=native non è il massimo, IMHO è buono solo per partire a scegliere l'ottimizzazione visto che attiva anche flag inutili).

Se proprio vuoi usare le use "a manina" in genere l'approccio 

```
USE="ssl sse sse2 ssse3 sse3 sse4_1"

USE="${USE} -ppp -gnome -gtk"
```

è preferibile.

Userei un ordine diverso, per mirror rsync andre ad usare europe direttamente e non dei mirror specifici etc.

@darkmanPPT: da quanto tempo non ti documenti? LDFLAGS="-Wl,-O1 -Wl,--as-needed" è il nuovo default e la tua impostazione è balorda, quanto come è perchè ci arrivi da solo, ma in ogni caso ti faccio notare che, se proprio vuoi, la sintassi corretta è

```
LDFLAGS="${LDFLAGS} -Wl,-z,now -Wl,--hash-style=gnu"
```

a meno che non ci siano seri e comprovati motivi per fare diversamente, ovviamente.

Idem con patate, solo in teoria, per CFLAGS anche se, al momento, non si è parlato di default, a parte mettere -fforce-addr per il profilo hardened, a suo tempo (idea abbandonata).

Se proprio vuoi alleggerire CFLAGS="-fomit-frame-pointer -g0" (ovviamente puoi è inutile che installi gdb e ricordo che -fomit-frame-pointer non è implicito, quando compili codice 32bit, per quel poco che mi è dato sapere) ma la discussione sull'ottimizzazione ed i limiti di native in un certo senso c'è già ed è pure "sticky".

----------

## stifler83

Grazie delle opinioni ragazzi, però per quanto riguarda le features nessuno sa darmi qualche consiglio?  :Smile: 

@djinnZ sto sistemando il CFLGS sperando di riuscire ad ottimizzarlo al meglio.

@darkmanPPT grazie anche a te per l'interessamento e l'aiuto.

----------

## djinnZ

 *stifler83 wrote:*   

> Grazie delle opinioni ragazzi, però per quanto riguarda le features nessuno sa darmi qualche consiglio? 

   :Confused: 

Facciamo conto che mi sono già fatto da solo il solito cazziatone perché ho risposto male, che ho già chiesto scusa etc. e la chiudiamo direttamente qui. Tanto lo sapete che non riesco a resistere.  :Laughing: 

dunque: features non c'è molto da scervellarsi, se ti serve il parallel fetch la abiliti, se hai una ciofeca di connessione la disabiliti, se hai pacchetti installati al di fuori di gentoo (a questo punto è meglio che ti rivolgi a cpan) disabiliti le collisioni, se hai ebuild ipersperimentali o scritti da fattoni ignoranti che si accavallano sui file di altri ebuild come prima, se non vuoi monnezza nei documenti ti levi la fetenzia di torno e via dicendo.

Dato che sono pigro ti mostro direttamente un esempio */etc/make.conf wrote:*   

> HOST="x86_64-pc-linux-gnu"
> 
> CFLAGS="-march=amdfam10 -mcx16 -msahf -mpopcnt --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -fomit-frame-pointer -O2 -g0"
> 
> # per gcc 3.x
> ...

 bada che -av come default non è bene, ti incasina il depclean ed emerge fallisce se usato in uno script (od in un for.).

ovviamente i colori stanno per: rogne (o le crea o le risolve) capriccio mio consigliato tranquillo link a quello che richiede

più o meno. Qualche errore ci sarà ma chissenefrega...

Per il resto arrangiati e spera.

tanto per dar fastidio faccio crossposting viso che la cosa riguarda anche quanto discusso qui. Per punizione, se e quando riuscirai a capire cosa volevo dire, riporterai nel corretto thread le ionformazioni.  :Laughing: 

... se solo emer[d|g]e non fosse così stupido da mettere anche le dir vuote in doc...

----------

## stifler83

Ma se volessi smaschera gcc-4.6.0 per poter utilizzare 

64 bit profile (amd64) for GCC 4.6

CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=corei7 -O2 -pipe"

CXXFLAGS="${CFLAGS}"

Dopo aver compilato gcc cosa dovrei ricompilare?   :Cool: 

@djinnZ Sto lavorando su tutto il make.conf e anche sull'interessante discorso che si affrontava nel link che mi hai incollato  :Wink: 

----------

## djinnZ

A parte che -march=corei7 è la stessa cosa che -mtune=generic -msse[1,2,3,4,...] -- param qualcosa etc.(non mi chiedere i parametri esatti, non mi ci levo la testa) ti ripeto che -march=native non si limita ad impostare -march ma imposta le dimensioni della cache ed anche altre cose.

Non dico di darti al ricering più balordo partendo da un -O9 ma non fermarti a -march=qualcosa -O2

Per mettere un nuovo gcc la via prudenziale è sempre la stessa: prima lo si installa, poi si compila (in pacchetto binario) libc, binutils e non ricordo più cosa, si installano i pacchetti binri nuovi (e non è male fare un backup, sempre tramite pacchetto binario) e si completa con il solito emerge -e @system && emerge -e @world. fatto questo pialli il vecchio gcc.

Il perchè dei pacchetti binari è che se mandi a donnine allegre le librerie di base puoi sempre usare il solito trucco dell'emerge --root... per rimettere a posto la versione funzionante.

A queste condizioni la prova la puoi fare, con una certa facilità. Se vuoi essere pignolo (se non vuoi perder tempo dietro a tentativi inutili IMHO) dai uno sguardo ai changelog degli ebuild od ai bug per vedere se non devi fare un upgrade di libc & c.

Non dico che se tiri su direttamente il nuovo gcc non funziona ma... meglio non stressarsi e far stressare il pc al posto nostro.

In alternativa ti crei un chroot e vedi se riesci a ricompilare (e qui sei moltoooo . più tranquillo).

Nulla toglie che puoi installare il nuovo gcc e fare qualche prova su specifici pacchetti, in tal caso bada solo a non fare l'idiota come il sottoscritto, ai tempi del 3.6 e del 4.x instabile solo per hardened, che mandò in gloria il sistema perchè si era scordato di riportare il default al gcc stabile prima di aggiornare il sistema. Uomo avvisato ...

----------

## stifler83

Questo è quello che ho attivo con march=native

```
cc -march=native -E -v - </dev/null 2>&1 | grep cc1

 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.5/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=256 -mtune=core2
```

@djinnZ ho capito che devo fare una personalizzazione, ma quello che ho scritto era per dire che se voglio utilizzare la flags per i7 e piu precisamente corei7-avx devo passare al nuovo gcc.

Per il resto è sempre aperta la discussione su come ottimizzare il make.conf   :Cool: 

----------

## djinnZ

uffa ...

-march=corei7

è la stessa cosa che 

-march=core2 -mcx16 -msahf -maes -msse4-avx -mpclmul -mpopcnt -mavx

e non ricordo che altro... (non sono io l'esperto di ottimizzazioni e non ricordo l'opzione esatta per see qual è)

Il codice prodotto sarà uguale.

Ora che mi ci fai pensare puoi provare ad installare direttamente il nuovo gcc e vedere se -march=native (e -march=corei7 --help:target nel malaugurato caso si fossero degnati di sistemarlo) ti attiva opzioni che non sono supportate dalla vecchia versione. Così lo sai per certo.; se ne vale proprio la pena.

Se per esempio con la nuova versione è stato introdotto uno specifico supporto (e relativa flag) per seeXXX o per ottimizzare solo codice 64 lahf invece che sahf allora ti serve per forza la nuova versione.

l'opzione -march implica -mtune che sostanzialmente non è altro che un insime di flag di ottimizzazione vere e proprie.

più o meno... (inorridisco all'approssimatività di quello che ho scritto)

libero di fare come credi ma sto cercando di farti capire che non dovrebbe esserci una grande differenza. E che le eventuali ottimizzazioni le puoi già attivare con il gcc stabile corrente. Ed è meglio... sempre che non siano state escluse perchè problematiche :Wink: 

----------

## stifler83

Ok grazie per l'aiuto e spero tanto che questo post sia utile per chi come me volesse customizzare il proprio sistema   :Wink: 

----------

