# [distcc] l'opzione -fpic

## cloc3

sto cercando di usare distcc per dare una mano a un portatile con una sola cpu.

mi sono accorto di due cose:

1. è necessario rendere esplicita, in make.conf, la CFLAG di compilazione, secondo il comando gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'.

2. è necessario aggiungere anche l'opzione -fpic, altrimenti quattro pacchetti su cinque saltano a metà compilazione.

vorrei sapere se l'opzione -fpic determina penalizzazioni di efficienza o di stabilità.

----------

## cloc3

metre attendevo una risposta ho capito che l'opzione -fpic, nel mio caso, non è una soluzione, ma un workaround per le compilazioni fallite che osservavo.

il modo corretto di agire, piuttosto, è rimuovere l'opzione -pipe, che non ha effetti sul codice compilato ma rende più spedita la compilazione.

lascio aperto il thread per eventuali commenti.

mi chiedo se non altro come gli howto disponibili in rete non mettono in guardia da questo fenomeno.

----------

## sabayonino

 *cloc3 wrote:*   

> 
> 
> mi chiedo se non altro come gli howto disponibili in rete non mettono in guardia da questo fenomeno.

 

L'How-To Ufficiale :

http://www.gentoo.org/doc/it/distcc.xml#doc_chap5

 *Quote:*   

> Alcuni pacchetti non usano distcc
> 
> Emergendo alcuni pacchetti, si noterà che non vengono distribuiti (e quindi non vengono compilati in parallelo). Ciò può accadere perché il Makefile del pacchetto non supporta le operazioni parallele, oppure perché il mantenitore dell'ebuild le ha disabilitate intenzionalmente a causa di un problema noto.
> 
> La compilazione può fallire anche con altri pacchetti per lo stesso identico motivo. Se dovesse capitare, segnalare un bug. 

 

distcc lo utilizzo pure io senza troppi problemi e senza alcun workaround....

mal che vada per i pacchi non compilati , faccio fare uno sforzo al piccolino.

PS : io la compilazione distribuita per la macchina meno potente non gliela faccio proprio eseguire. solo agli host remoti faccio compilari i pacchetti in quanto ho notato che essendo troppo lenta , mi rallentava tutta la distribuzione della compilazione perchè dei "pezzi" di compilazione degli altri host dovevano aspettare la lumaca (non sempre...) .

----------

## cloc3

 *sabayonino wrote:*   

> 
> 
> distcc lo utilizzo pure io senza troppi problemi e senza alcun workaround....
> 
> 

 

in effetti, anche qui da me qualcosa è cambiato.

sto ripetutamente provando a ricompilare il pacchetto media-libs/libkate con l'opzione -pipe, a cui prima avevo attribuito la colpa dei miei failure, ma tutto va liscio fino in fondo. evidentemente il guasto era altrove ed è stato rimosso.

sono molto contento di distcc. in precedenza il metodo portatile felice, che mi piace un sacco, ma adesso non riesco più a fare chroot da remoto perchè sto usando codice ottimizzato per i rispettivi processori.

il mio portatile è un corei7-avx, dunque non così lento, ma monoprocessore (temevo, altrimenti, che avrebbe scaldato troppo).

con il nuovo assetto, ho portato la compilazione di libreoffice da 14 ore e rotti e 2:35.

----------

## sabayonino

quel procio ce l'ho pure io.

corei7-avx mi ha creato problemi  mi sembra su libreoffice

ho optato per corei7 e basta  su distcc  per il portatile.

invece fuzniona senza problemi sulla mobo

con distcc mi raccomando .... controlla sempre di non lasciare (native) da qualche parte   :Very Happy: 

ne ho lasciato uno per sbaglio ed ho imprecato per un buon pomeriggio prima di capire perchè quasi tutte le compilazioni fallivano   :Mr. Green: 

----------

## ago

Io ti consiglierei più una soluzione tipo questa: https://forums.gentoo.org/viewtopic-p-7355568-highlight-.html#7355568

----------

## cloc3

 *ago wrote:*   

> Io ti consiglierei più una soluzione tipo questa: https://forums.gentoo.org/viewtopic-p-7355568-highlight-.html#7355568

 

certo. il repository di binari può essere una ottima soluzione.

nel mio caso, preferisco distcc perché ho personalizzato le CFLAGS in un modo spinto, al punto da non poterci fare chroot da processore remoto non compatibile. i repository, al contrario, si usano quando si desidera distribuire i pacchetti a macchine indipendenti e si scelgono, di conseguenza, impostazioni largamente condivisibili.

----------

## ago

 *cloc3 wrote:*   

> i repository, al contrario, si usano quando si desidera distribuire i pacchetti a macchine indipendenti e si scelgono, di conseguenza, impostazioni largamente condivisibili.

 

No.

Questo repository e di conseguenza l'intera vm è solo per un pc, con le cflags adatte e non generiche.

----------

## cloc3

 *ago wrote:*   

>  *cloc3 wrote:*   i repository, al contrario, si usano quando si desidera distribuire i pacchetti a macchine indipendenti e si scelgono, di conseguenza, impostazioni largamente condivisibili. 
> 
> No.
> 
> Questo repository e di conseguenza l'intera vm è solo per un pc, con le cflags adatte e non generiche.

 

ma se tu avessi motli portatili, con hardware differente, come ti organizzeresti, per evitare distcc?

----------

## ago

 *cloc3 wrote:*   

> ma se tu avessi motli portatili, con hardware differente, come ti organizzeresti, per evitare distcc?

 

Più vm, ogni vm deve essere identica al sistema sul portatile. In ogni caso a mio avviso mettere dozzine di cflags non aumenta le prestazioni, anche generiche vanno benone

----------

## sabayonino

molti pc ? quoto per cflags generiche se il parco macchine è abbastanza omogeneo

altrimenti cambi le flags per ogni pc che compili   :Twisted Evil: 

----------

## djinnZ

La soluzione più performante su singola macchina sarebbe catalyst+repository binario ma non mi sono ancora applicato, nonostante mi riprometta di farlo da sempre.

A quel punto il tempo effettivo di compilazione avrebbe un rilevo assai relativo (lasci il pc dedicato a ravanare e tanti saluti).

Al momento mi basta il chroot visto che non ho macchine tanto disomogenee ma per il futuro credo che dovrò mettermi a studiare il funzionamento di catalyst.. 

Libreoffice mi pare un tantino strano (è una di quelle cose che aggiorno solo di notte quindi non ho mai verificato quanto ci mette), si vede che hanno fatto passi da gigante rispetto a openoffice che non ammetteva la compilazione parallela nei makefile.

----------

## sabayonino

 *djinnZ wrote:*   

> (è una di quelle cose che aggiorno solo di notte quindi non ho mai verificato quanto ci mette)

 

Genlop

```
# emerge genlop -a
```

```
genlop -et libreoffice

 * app-office/libreoffice

     Wed Aug  7 04:33:26 2013 >>> app-office/libreoffice-4.0.4.2

       merge time: 3 hours, 26 minutes and 45 seconds.
```

----------

