upgrade to gcc 4.7
Moderatore: Staff
Regole del forum
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
upgrade to gcc 4.7
Questo topic è rivolto soprattutto ai pacchettizzatori, ma interessa tutti, quindi non lo metto nell'area riservata.
Non so quanto manchi all'uscita di slackware 14, ma la current al momento usa gcc 4.7
Questo introduce un po' di problemi (v. http://gcc.gnu.org/gcc-4.7/porting_to.html) in quanto alcune funzionalità in stato 'deprecating' fino a poco tempo fa fornivano solamente dei warning in fase di compilazione suppongo, e suppongo altrettanto che molti sviluppatori hanno ignorato la cosa.
Ora che queste sono passate in 'deprecated' molti programmi falliscono la compilazione.
Per esempio, compilando chromium 20 su current mi sono accorto di errori tipo
"ssize_t non dichiarato"
"geteuid non dichiarato"
ecc...,
anche mettendo l'opzione -Dgcc_version=47
Il link di cui sopra suggerisce ai programmatori di aggiungere #include <unistd.h> al codice che da quello che ho capito veniva prima incluso tipo implicitamente in precedenza, o quasi.
Per farla breve, per compilare chromium ho dovuto settare
CXXFLAGS="-include unistd.h"
(non CFLAGS perchè fallivano solo i "g++"; "cc" veniva usato per compilare codice assembler e unistd.h gli dava fastidio)
E se il problema si presenta con chromium 20 (che comunque non ho terminato di compilare per problemi al linking, ma il building è passato correttamente), suppongo che si presenterà anche in altro software
Suggerisco di cominciare a fare qualche test compilando in current.
Non so quanto manchi all'uscita di slackware 14, ma la current al momento usa gcc 4.7
Questo introduce un po' di problemi (v. http://gcc.gnu.org/gcc-4.7/porting_to.html) in quanto alcune funzionalità in stato 'deprecating' fino a poco tempo fa fornivano solamente dei warning in fase di compilazione suppongo, e suppongo altrettanto che molti sviluppatori hanno ignorato la cosa.
Ora che queste sono passate in 'deprecated' molti programmi falliscono la compilazione.
Per esempio, compilando chromium 20 su current mi sono accorto di errori tipo
"ssize_t non dichiarato"
"geteuid non dichiarato"
ecc...,
anche mettendo l'opzione -Dgcc_version=47
Il link di cui sopra suggerisce ai programmatori di aggiungere #include <unistd.h> al codice che da quello che ho capito veniva prima incluso tipo implicitamente in precedenza, o quasi.
Per farla breve, per compilare chromium ho dovuto settare
CXXFLAGS="-include unistd.h"
(non CFLAGS perchè fallivano solo i "g++"; "cc" veniva usato per compilare codice assembler e unistd.h gli dava fastidio)
E se il problema si presenta con chromium 20 (che comunque non ho terminato di compilare per problemi al linking, ma il building è passato correttamente), suppongo che si presenterà anche in altro software
Suggerisco di cominciare a fare qualche test compilando in current.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: upgrade to gcc 4.7
Ecco un altro esempio:
Dallo slackbuild di seamonkey di pat per current:
A proposito di seamonkey credo di aver trovato un bug, o meglio, una discrepanza tra lo slackbuild e quello che trovo in /var/log/{packages,script}
A tal scopo mi sto scaricando lo sb di seamonkey e ricompilarlo passo passo per indagare.
EDIT:
Confermo il bug dello slackbuild di seamonkey 2.9
Fino a seamonkey 2.0.x il make install installava le nss-include in /usr/include/seamonkey-*/nss
Dal seamonkey 2.1 il make install installa le nss-include in /usr/include/seamonkey-*/ e non crea la directory nss. Visto che alcuni software continuano a cercare queste include in nss e lo stesso pkgconfig segnala ancora ../nss, lo slackbuild crea il link /usr/include/seamonkey-*/nss -> /usr/include/seamonkey-* (ln -s . nss)
A quanto pare però in seamonkey 2.9 il make install CREA la directory nss ma la lascia vuota. Ovviamente fallisce la creazione del link, quindi gli applicativi in quel percorso non trovano nulla e falliscono la compilazione.
EDIT2:
Continuando la compilazione di chromium, sono arrivato finora a questi workaround:
il -I/usr/include/seamonkey/ è per il bug di seamonkey sopradescritto
il -include unistd.h è per il problema di gcc4.7 che non se lo prende in automatico
il -include /usr/include/expat.h è perchè l'include path è -I/usr/include/seamonkey/ -I/usr/include/ e non viceversa, così si prende expat.h di seamonkey che non matcha con expat installato sul sistema.
il -lnssutil3 è perchè uno dei simboli durante il linking è definito in libnssutil3.so che è una dipendenza di libnss3.so e il linker punta solo a quest'ultimo, ma gcc4.7 sembrerebbe non risolvere la dipendenze implicita ma la vuole implicita.
Ma non è ancora finita!!!
EDIT3: erratacorrige su nssutil3. Il problema non è di gcc4.7 ma di seamonkey >=2.8 ; questo infatti, a differenza dei precedenti, crea nssutil3 che prima non esisteva proprio. Purtroppo non è stato aggiornato il relativo /usr/lib64/pkgconfig/nss.pc
Come workaround al momento ho aggiornato questo file, ma lo saprò tra qualche ora se ha funzionato (ho dovuto rilanciare la compilazione da 0)
Con la sintassi di cui sopra ( -Dlibraries_for_target="-lnssutils3" \ ) sovrascrive tutte le librerie e ci lascia solo questa.. poco utile
Dallo slackbuild di seamonkey di pat per current:
Codice: Seleziona tutto
if gcc --version | grep -q "gcc (GCC) 4.7.0" ; then
# Enable compiling with gcc-4.7.0:
sed -i '/fcntl.h/a#include <unistd.h>' \
mozilla/ipc/chromium/src/base/{file_util_linux,message_pump_libevent,process_util_posix}.cc &&
sed -i '/sys\/time\.h/a#include <unistd.h>' mozilla/ipc/chromium/src/base/time_posix.cc &&
sed -i 's#\"PRIxPTR#\" PRIxPTR#g' mozilla/layout/base/tests/TestPoisonArea.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/base/search/src/nsMsgSearchAdapter.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/base/src/nsMsgFolderCompactor.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/compose/src/nsSmtpProtocol.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/imap/src/nsImapMailFolder.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/imap/src/nsImapProtocol.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/imap/src/nsImapServerResponseParser.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/local/src/nsPop3Protocol.cpp &&
sed -i 's#\"CRLF#\" CRLF#g' mailnews/mime/src/mimedrft.cpp &&
sed -i 's#\"messaggio_LINEBREAK#\" messaggio_LINEBREAK#g' mailnews/mime/src/mimemult.cpp &&
sed -i 's#\"messaggio_LINEBREAK#\" messaggio_LINEBREAK#g' mailnews/base/src/nsMsgFolderCompactor.cpp &&
sed -i 's# ""##' mozilla/browser/base/Makefile.in
fi
A tal scopo mi sto scaricando lo sb di seamonkey e ricompilarlo passo passo per indagare.
EDIT:
Confermo il bug dello slackbuild di seamonkey 2.9
Fino a seamonkey 2.0.x il make install installava le nss-include in /usr/include/seamonkey-*/nss
Dal seamonkey 2.1 il make install installa le nss-include in /usr/include/seamonkey-*/ e non crea la directory nss. Visto che alcuni software continuano a cercare queste include in nss e lo stesso pkgconfig segnala ancora ../nss, lo slackbuild crea il link /usr/include/seamonkey-*/nss -> /usr/include/seamonkey-* (ln -s . nss)
A quanto pare però in seamonkey 2.9 il make install CREA la directory nss ma la lascia vuota. Ovviamente fallisce la creazione del link, quindi gli applicativi in quel percorso non trovano nulla e falliscono la compilazione.
EDIT2:
Continuando la compilazione di chromium, sono arrivato finora a questi workaround:
Codice: Seleziona tutto
build/gyp_chromium -f make build/all.gyp --depth=. \
-Drelease_extra_cflags="${CFLAGS} -I/usr/include/seamonkey/" \
-Dlibraries_for_target="-lnssutils3" \
...
CFLAGS=" $SLKCFLAGS" \
CXXFLAGS="-include /usr/include/expat.h -include unistd.h $SLKCFLAGS" \
make chrome chrome_sandbox BUILDTYPE=Release
il -include unistd.h è per il problema di gcc4.7 che non se lo prende in automatico
il -include /usr/include/expat.h è perchè l'include path è -I/usr/include/seamonkey/ -I/usr/include/ e non viceversa, così si prende expat.h di seamonkey che non matcha con expat installato sul sistema.
il -lnssutil3 è perchè uno dei simboli durante il linking è definito in libnssutil3.so che è una dipendenza di libnss3.so e il linker punta solo a quest'ultimo, ma gcc4.7 sembrerebbe non risolvere la dipendenze implicita ma la vuole implicita.
Ma non è ancora finita!!!
EDIT3: erratacorrige su nssutil3. Il problema non è di gcc4.7 ma di seamonkey >=2.8 ; questo infatti, a differenza dei precedenti, crea nssutil3 che prima non esisteva proprio. Purtroppo non è stato aggiornato il relativo /usr/lib64/pkgconfig/nss.pc
Come workaround al momento ho aggiornato questo file, ma lo saprò tra qualche ora se ha funzionato (ho dovuto rilanciare la compilazione da 0)
Con la sintassi di cui sopra ( -Dlibraries_for_target="-lnssutils3" \ ) sovrascrive tutte le librerie e ci lascia solo questa.. poco utile
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: upgrade to gcc 4.7
Wow, ha compilato!
Ci sono ancora altri problemi. Appena risolvo pure quelli lo uppo.
a runtime:
E difatti non funziona bene (la barra dell'url e dei tab è rossa)
EDIT: Anche questo è risolto, ma prima di caricare devo ricompilare (sarebbe sufficiente un repackage, ma ho modificato lo slackbuild e voglio caricare cose pulite)
Codice: Seleziona tutto
PKG_CONFIG_PATH=$CWD:$PKG_CONFIG_PATH \
build/gyp_chromium -f make build/all.gyp --depth=. \
-Drelease_extra_cflags="$SLKCFLAGS ${CFLAGS}" \
...
CXXFLAGS="-include /usr/include/expat.h -include unistd.h" \
make chrome chrome_sandbox BUILDTYPE=Release
a runtime:
Codice: Seleziona tutto
[2:2:1530488200:ERROR:resource_bundle.cc(97)] Failed to load /usr/lib64/chromium/theme_resources_standard.pak
Some features may not be available.
[2:2:1530488282:ERROR:resource_bundle.cc(97)] Failed to load /usr/lib64/chromium/ui_resources_standard.pak
Some features may not be available.
[23556:23556:1530532874:ERROR:resource_bundle.cc(97)] Failed to load /usr/lib64/chromium/theme_resources_standard.pak
Some features may not be available.
[23556:23556:1530533129:ERROR:resource_bundle.cc(97)] Failed to load /usr/lib64/chromium/ui_resources_standard.pak
Some features may not be available.
(chromium:23556): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.
(chromium:23556): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.
EDIT: Anche questo è risolto, ma prima di caricare devo ricompilare (sarebbe sufficiente un repackage, ma ho modificato lo slackbuild e voglio caricare cose pulite)
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: upgrade to gcc 4.7
ECCOLOOO.
Beh, si, sono andato parzialmente OT, però è compilando chromium che ho scoperto il problema con gcc 4.7 e seamonkey.
vabbé, me la sto a cantà e suonà da solo
In verità questo topic non è nato assolutamente per chiedere una risoluzione dei i miei problemi con chromium.
Anzi, visto che lo stesso problema mi si era già presentato in slackyd cercavo riscontri se fosse successo anche ad altri, soprattutto in vista (anche se in lontananza) di slackware 14 e i relativi problemi che potremmo trovare nel nuovo repository.
Beh, si, sono andato parzialmente OT, però è compilando chromium che ho scoperto il problema con gcc 4.7 e seamonkey.
vabbé, me la sto a cantà e suonà da solo
In verità questo topic non è nato assolutamente per chiedere una risoluzione dei i miei problemi con chromium.
Anzi, visto che lo stesso problema mi si era già presentato in slackyd cercavo riscontri se fosse successo anche ad altri, soprattutto in vista (anche se in lontananza) di slackware 14 e i relativi problemi che potremmo trovare nel nuovo repository.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: upgrade to gcc 4.7
WOW,
rientro nei contributori di slackware
Adesso però devo ricompilare chromium
rientro nei contributori di slackware
http://www.linuxquestions.org/questions ... ss-942426/xap/seamonkey-2.9.1-x86_64-1.txz: Upgraded.
This is a bugfix release.
Fixed POP3 filters that move mail to IMAP folders.
Fixed loading message body in sub-folders that use fetch headers only.
Addressed mail notification issues.
Fixed crash in nMsgDatabase.
Also, the build script and seamonkey-nss.pc were adjusted to fix issues
with compiling against Seamonkey NSS. Thanks to zerouno on LQ.
Adesso però devo ricompilare chromium
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111