Quali pacchetti devono essere ricostruiti dopo l'aggiornamento gccsu un sistema Gentoo? È sufficiente correre
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
come suggerito simile per perl in questa FAQ ?
Quali pacchetti devono essere ricostruiti dopo l'aggiornamento gccsu un sistema Gentoo? È sufficiente correre
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
come suggerito simile per perl in questa FAQ ?
Risposte:
TL; DR
Ho un approccio diverso su questo come utente Gentoo. Mentre sono d'accordo con l'approccio di peterph di "Let the System Decide", non sono d'accordo quando si tratta di un aggiornamento ABI . Un aggiornamento ABI è talvolta un cambiamento importante nel comportamento. Nel caso di GCC 4.7, la modifica ABI è stata l'adozione del nuovo standard C ++ 11, che anche il peterph ha sottolineato.
Ecco perché scrivo questa risposta. Sono un drogato di standard. Ho iniziato nel mondo del web quando c'erano circa 4 browser diversi e una pletora di tag in HTML che erano supportati solo da alcuni browser. All'epoca, tutti quei tag aumentavano la confusione e l'IMO rendeva il lavoro più difficile. Il C ++ è stato standardizzato per lo stesso motivo, in breve in modo da poter compilare il codice che scrivo e posso compilare il codice che scrivi . Se decidiamo di non seguire uno standard, perdiamo la libertà di condividere.
C ++ 98 è lo standard approvato da 13 anni. Il C ++ 11 è stato ratificato dal Comitato ISO nel 2011 ed è stato completamente integrato in GCC 4.7. Visualizza lo stato ISO corrente e il nuovo standard ISO .
Come utenti di una distribuzione basata sul codice sorgente, abbiamo l'opportunità unica di modellare il comportamento futuro di un pacchetto perché lo compiliamo prima di utilizzarlo. Pertanto, per prepararmi a tale opportunità, ritengo che i seguenti comandi debbano essere eseguiti durante l'aggiornamento al nuovo compilatore:
emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system
Il primo sistema pass-through crea il nuovo compilatore e le sue dipendenze con il vecchio compilatore. Il secondo sistema pass-through ricostruisce il nuovo compilatore e le sue dipendenze con il nuovo compilatore. In particolare, vogliamo farlo in modo che la nostra Build Chain sfrutti le nuove funzionalità del nuovo compilatore, se anche i pacchetti Build Chain sono stati aggiornati ... Alcune persone sostituiscono il secondo sistema pass-through con il mondo impostato, sebbene io troviamo che questo sia eccessivo, poiché non sappiamo quali pacchetti supportano già il nuovo standard, ma vogliamo che la nostra catena di build si comporti in modo sano.
In questo modo almeno per il set di sistema, ci prepara a testare ogni pacchetto che compiliamo in base al nuovo standard, perché utilizziamo una versione progressiva. In questo modo, l'aggiunta -std=c++11a CXXFLAGSdopo l'aggiornamento della catena di build ci consente di testare la rottura ed essere in grado di inviare i bug direttamente al nostro bugzilla o upstream agli sviluppatori reali per la semplice ragione di:
Ehi, il tuo pacchetto blah blah si rompe usando il nuovo standard C ++ e ho allegato il mio registro di build.
Lo considero una cortesia per gli sviluppatori, poiché ora hanno il tempo di prepararsi man mano che lo standard viene adottato più ampiamente e il vecchio standard viene gradualmente eliminato. Immagina il trambusto da parte dello sviluppatore se ha ricevuto centinaia di bug, perché ha aspettato che lo standard fosse gradualmente eliminato ...
Nessun'altra distribuzione di cui sia a conoscenza può utilizzare questo metodo in quanto gli attuali manutentori del pacchetto esistono come intermediari prima che una rispettiva patch o un aggiornamento possano essere utilizzati dalla rispettiva comunità di utenti. Abbiamo manutentori, ma abbiamo anche la possibilità di usare un portage tree locale.
Non so se la generosità sia stata pubblicata perché a tutti voi piacciono le mie perspicaci e ben ponderate risposte, ma nel tentativo della generosità, cercherò di rispondere alla vostra perspicace, ben ponderata offerta di generosità. Prima di tutto, lasciami dire in risposta che come utente di una distribuzione basata sulla fonte, credo fermamente che ciò che collega i punti sono tutte le cose che hai richiesto nella tua richiesta di ricompensa. Qualcuno può essere un grande programmatore, ma ha una cura scadente per il software. Allo stesso modo, ci sono persone che sono programmatori schifosi che hanno molta cura del software.
Prima di venire qui, ero un avido poster ai Forum di Gentoo . Alla fine mi sono reso conto quando ho iniziato a venire qui che tutti hanno un certo grado di talento che possono usare. È quello che scelgono di farne che fa la differenza. Alcuni di noi sono grandi scrittori (non io), quindi se vuoi contribuire a qualche progetto, ma non scrivi o non riesci a scrivere codice o correggere bug, ricorda che i grandi scrittori possono scrivere un'ottima documentazione o grandi articoli Wiki .
Lo standard è lì per un altro motivo: in una comunità, ci si aspettano alcune regole dai suoi membri . Segui anche questa affermazione qui. Se invio una correzione, una patch, un miglioramento, ecc. E non ci sono standard, la patch funzionerà solo nelle situazioni che ritengo importanti, cioè se sto usando whizbang compilatore 2.0 e la patch è costruita contro whizbang compilatore 1.0, avrà esito negativo. Poiché lo sforzo è rivolto a una comunità, la comunità si aspetta che tutto funzioni nella maggior parte delle situazioni, quindi invece di forzare tutti gli utenti a eseguire l'aggiornamento al compilatore 2, posso stipulare uno standard:
Questo pacchetto sceglie di consentire la compatibilità con le versioni precedenti di Whizbang Compiler 1.0
In questo modo, come sviluppatore, programmatore schifoso o meno, so che devo usare o almeno provare con Compiler Versione 1.0. Come utente, d'altra parte, posso scegliere cosa voglio fare. Se non sono soddisfatto, posso richiedere una patch, inviando un bug, o l'altro estremo di "Questo software è un pezzo di merda!" E non fare nulla. Indipendentemente da ciò, l'utente e lo sviluppatore comprendono lo standard perché è stato scritto.
Colmare il divario agisce in qualche modo da parte di un utente, e ciò richiede tutto ciò che hai chiesto a me e agli altri di commentare, e dobbiamo fare affidamento sulla comunità di utenti e il loro talento in tutte le forme per colmare quel divario. Se scegli di essere uno degli utenti che contribuiscono, ti applaudo. Per quelli di voi che scelgono di essere inattivi, ricordate che se volete qualcosa di riparato, quelli attivi hanno bisogno del vostro contributo. Quindi ti sto dicendo, non essere timido nel presentare un bug o nel dirci che dobbiamo aggiornare la documentazione, e se siamo scortesi, informaci o trova qualcun altro, finché non trovi la tua area di competenza.
Dipende molto dal tipo di aggiornamento del compilatore che hai fatto. Se è stato sostanziale, allora tutto dovrebbe essere ricompilato *) a causa di possibili modifiche nell'ABI da parte del compilatore. In molti casi non sarà necessario, ma se i tuoi pacchetti dipendono da qualcosa come C ++ 11, potresti incorrere in problemi - vedi ad esempio le notizie di Gentoo sulla modifica di ABI in GCC 4.7 o GCC bugzilla .
*) Nota l'enfasi sul "ricompilato" - sicuramente non ha molto senso ricompilare (leggi ricostruzione) un'applicazione Python o Perl perché hai cambiato un compilatore C. A meno che non abbia anche un componente nativo (che potrebbe anche).