[SOLVED] l'aggiornamento di icu4c ha fatto una strage

Se avete problemi con l'installazione e la configurazione di Slackware64 postate qui. Non usate questo forum per argomenti che trattano la Slackware32 o generali... per quelli usate rispettivamente il forum Slackware e Gnu/Linux in genere.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware64 usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
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.
gian_d
Linux 0.x
Linux 0.x
Messaggi: 88
Iscritto il: mer lug 16, 2014 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 4.19.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

[SOLVED] l'aggiornamento di icu4c ha fatto una strage

Messaggioda gian_d » gio ott 17, 2019 19:56

Il recente aggiornamento di icu4c dalla versione 64 alla 65 ha coinvolto anche qt5 (nella compilazione era abilitata l'opzione -icu) e a scalare sembrano taroccate varie applicazioni che usano Qt5 come dipendenza (es. vlc, di sicuro).
Fin qui poco male, ieri mi sono armato di pazienza e ho avviato una nuova compilazione di Qt5 ma, purtroppo, la compilazione si arresta perché lasciando l'opzione -icu vengono linkate le librerie della versione 64. Ho provato a cercare in rete una soluzione per fare una compilazione pulita ma non ho trovato nulla e mettermi a rovistare nei sorgenti di Qt5 non mi sembra proprio il caso.

Per ora l'unica soluzione alla mia portata da applicarsi temporaneamente mi sembra questa: https://www.linuxquestions.org/question ... ost5916233 . Cito:
So what you need to do is keep copies of libicudata.so.61, libicui18n.so.61, libicuio.so.61, libicutest.so.61, libicutu.so.61 and libicuuc.so.61 from icu4c-61.1-i586-2.txz or icu4c-61.1-x86_64-2.txz (discard the rest), and put them in a icu4c-compat package which contains the shared libraries for all the versions of icu4c that you have things linking against


In sostanza si tratta di fare un pacchetto contenente le librerie della versione 64 in modo da mantenere una retrocompatibilità di icu4c in attesa di una patch o di un aggiornamento di Qt5. Tuttavia ho due dubbi:
1) la coesistenza delle librerie 64 e 65 potrebbe creare problemi per successive compilazioni di sorgenti che linkano regolarmente le librerie di icu4c-65?
2) devo creare un pacchetto "icu4c-compat" (come suggerito nel post) contenente esclusivamente le librerie libicu*.so.64 da installare in aggiunta al pacchetto ordinario di icu4c rilasciato da Slackware64 current oppure devo creare un pacchetto personalizzato contenente tutti i file di icu4c-65 e in aggiunta le librerie *so.64 ? La prima opzione mi sembra più pulita ma non mi convince molto

Se poi ci sono già soluzioni più pulite che permettano una compilazione di Qt5 che linka regolarmente icu4c-65 ringrazio per i suggerimenti. Una cosa è certa: non mi sembra il caso di mettermi a fare tentativi da niubbo alla cieca per una compilazione che richiede 10 ore. Mi era già capitato una volta un errore dopo 9 ore di compilazione ed è un trauma che non voglio rivivere :-D
Ultima modifica di gian_d il ven ott 18, 2019 14:10, modificato 1 volta in totale.

gian_d
Linux 0.x
Linux 0.x
Messaggi: 88
Iscritto il: mer lug 16, 2014 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 4.19.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: l'aggiornamento di icu4c ha fatto una strage

Messaggioda gian_d » gio ott 17, 2019 20:00

PS: in alternativa si potrebbe disabilitare l'opzione -icu nella compilazione di Qt5, ma non ho idea degli eventuali limiti che avrebbe l'installazione della piattaforma senza il supporto di icu4c

hashbang
Packager
Packager
Messaggi: 1975
Iscritto il: ven giu 04, 2010 10:27
Nome Cognome: Luca De Pandis
Distribuzione: macOS Catalina
Località: Lecce / Bergamo / Milano
Contatta:

Re: l'aggiornamento di icu4c ha fatto una strage

Messaggioda hashbang » gio ott 17, 2019 20:10

gian_d ha scritto:1) la coesistenza delle librerie 64 e 65 potrebbe creare problemi per successive compilazioni di sorgenti che linkano regolarmente le librerie di icu4c-65?
Nì.
Solitamente la maggior parte dei software usa pkg-config e/o autotools+libtool per ottenere i parametri corretti da passare a ld. Tuttavia non è matematico, e potresti incorrere in casi in cui il software linki o, addirittura, fallisca la compilazione perché le API referenziate ed esposte nell'header non corrispondono a quelle della libreria, in quanto ha preso la versione sbagliata. In questi casi è meglio usare path non standard e andare di LD_LIBRARY_PATH.

2) devo creare un pacchetto "icu4c-compat" (come suggerito nel post) contenente esclusivamente le librerie libicu*.so.64 da installare in aggiunta al pacchetto ordinario di icu4c rilasciato da Slackware64 current oppure devo creare un pacchetto personalizzato contenente tutti i file di icu4c-65 e in aggiunta le librerie *so.64 ? La prima opzione mi sembra più pulita ma non mi convince molto
Solo con le librerie di compatibilità che ti servono. La versione successiva si presume sia inclusa nel pacchetto ufficiale, no?

Se poi ci sono già soluzioni più pulite che permettano una compilazione di Qt5 che linka regolarmente icu4c-65 ringrazio per i suggerimenti. Una cosa è certa: non mi sembra il caso di mettermi a fare tentativi da niubbo alla cieca per una compilazione che richiede 10 ore. Mi era già capitato una volta un errore dopo 9 ore di compilazione ed è un trauma che non voglio rivivere :-D
Beh nella stragrande maggioranza dei casi se dai un make ad un software che ha fallito la compilazione, non ricompila tutto. I codici oggetto generati non vengono ricostruiti, a meno di modifiche ai parametri di compilazione o modifiche al codice, tali per cui il codice oggetto generato è diverso dal precedente.
Detto ciò, se devi compilare robe così impegnative usa ccache.

gian_d
Linux 0.x
Linux 0.x
Messaggi: 88
Iscritto il: mer lug 16, 2014 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 4.19.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: l'aggiornamento di icu4c ha fatto una strage

Messaggioda gian_d » gio ott 17, 2019 20:32

[conflittato da hashbang, che leggo dopo]
Aggiornamento: ho lasciato l'installazione di icu4c-65 rilasciato da current e ho installato un pacchetto icu4c-compat contenente esclusivamente le librerie libicu*.so.64.2 e il file install/doinst.sh. In quest'ultimo ho lasciato solo le righe che creano i collegamenti simbolici *.so.64 a *.so.64.2, in modo che i link simbolici libicu*.so puntino regolarmente a libicu*so.65.

Fatto questo ho reinstallato il pacchetto qt5 che avevo conservato dalla precedente compilazione e sembra che funzioni regolarmente. Ad esempio vlc si avvia regolarmente.

gian_d
Linux 0.x
Linux 0.x
Messaggi: 88
Iscritto il: mer lug 16, 2014 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 4.19.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: l'aggiornamento di icu4c ha fatto una strage

Messaggioda gian_d » gio ott 17, 2019 20:48

hashbang ha scritto:Nì.
Solitamente la maggior parte dei software usa pkg-config e/o autotools+libtool per ottenere i parametri corretti da passare a ld. Tuttavia non è matematico, e potresti incorrere in casi in cui il software linki o, addirittura, fallisca la compilazione perché le API referenziate ed esposte nell'header non corrispondono a quelle della libreria, in quanto ha preso la versione sbagliata. In questi casi è meglio usare path non standard e andare di LD_LIBRARY_PATH.

Perfetto, vuol dire che se incontrerò qualche problema del genere almeno so dove andare a parare, grazie per la dritta!

2) devo creare un pacchetto "icu4c-compat" (come suggerito nel post) contenente esclusivamente le librerie libicu*.so.64 da installare in aggiunta al pacchetto ordinario di icu4c rilasciato da Slackware64 current oppure devo creare un pacchetto personalizzato contenente tutti i file di icu4c-65 e in aggiunta le librerie *so.64 ? La prima opzione mi sembra più pulita ma non mi convince molto
Solo con le librerie di compatibilità che ti servono. La versione successiva si presume sia inclusa nel pacchetto ufficiale, no?

Esatto, come ho scritto nel post precedente ho lasciato l'installazione del pacchetto ufficiale e aggiunto un pacchetto ridotto contenente esclusivamente le librerie della versione precedente e sembra che funzioni.

Se poi ci sono già soluzioni più pulite che permettano una compilazione di Qt5 che linka regolarmente icu4c-65 ringrazio per i suggerimenti. Una cosa è certa: non mi sembra il caso di mettermi a fare tentativi da niubbo alla cieca per una compilazione che richiede 10 ore. Mi era già capitato una volta un errore dopo 9 ore di compilazione ed è un trauma che non voglio rivivere :-D
Beh nella stragrande maggioranza dei casi se dai un make ad un software che ha fallito la compilazione, non ricompila tutto. I codici oggetto generati non vengono ricostruiti, a meno di modifiche ai parametri di compilazione o modifiche al codice, tali per cui il codice oggetto generato è diverso dal precedente.
Detto ciò, se devi compilare robe così impegnative usa ccache.

Ho notato che Qgis si comporta così, in effetti lascia invariato il codice già generato regolarmente, ma la mia impressione è che questo dipenda dal codice dello slackbuild specifico perché, se non sbaglio, lo slackbuild dovrebbe rimuovere le directory create in /tmp/SBo.
In ogni modo ho toccato con mano l'opportunità di usare ccache. In passato nelle compilazioni di Qt5 che ho fatto lasciavo disabilitata l'opzione di ccache, ma mi andava bene perché terminavano regolarmente. Ma l'esperienza di ieri suggerisce di spendere un po' di tempo in più all'inizio per evitare inutili reiterazioni in caso di errori :-)

Avatar utente
ponce
Iper Master
Iper Master
Messaggi: 2636
Iscritto il: mer mar 05, 2008 16:45
Nome Cognome: Matteo Bernardini
Slackware: slackware64-current
Kernel: 5.3.2
Desktop: lxde
Località: Pisa
Contatta:

Re: l'aggiornamento di icu4c ha fatto una strage

Messaggioda ponce » gio ott 17, 2019 23:00

io qt5 lo compilo from scratch insieme alle sue dipendenze e funziona tranquillamente: probabilmente hai dei problemi di cose che linkano ancora alle vecchie librerie icu4c perche' non hai ricompilato anche le dipendenze (obbligatorie e opzionali).

gian_d
Linux 0.x
Linux 0.x
Messaggi: 88
Iscritto il: mer lug 16, 2014 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 4.19.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: l'aggiornamento di icu4c ha fatto una strage

Messaggioda gian_d » ven ott 18, 2019 1:34

Deve essere così allora. In effetti ci sono libxkbcommon, snappy e qualche altra dipendenza che non ho ricompilato dopo l'aggiornamento. Vi farò sapere!

gian_d
Linux 0.x
Linux 0.x
Messaggi: 88
Iscritto il: mer lug 16, 2014 17:35
Nome Cognome: Giancarlo Dessì
Slackware: 64 current
Kernel: 4.19.xx
Desktop: KDE 4.14.38
Località: Sardinia
Contatta:

Re: [SOLVED] l'aggiornamento di icu4c ha fatto una strage

Messaggioda gian_d » ven ott 18, 2019 14:14

Grazie al rilievo di Ponce, ieri notte ho ricompilato le dipendenze di Qt5 e poi ho avviato la ricompilazione di Qt5, terminata con successo un'ora e mezza fa. Tutto OK, il problema era tutto mio :-)