gwenview non funziona [risolto]

[Rama]

non si apre:

bash-5.1$ gwenview
gwenview: /usr/lib64/libgomp.so.1: version `GOMP_4.5' not found (required by /usr/lib64/libraw.so.20)

può dipendere dal kernel che ho compilato?
non voglio riavviare per provare col kernel dell'istallazione perché sto testando la macchina dopo i guai descritti in un altro post;

[erio]

sembra che libgomp sia parte delle gcc, ma non sono sicuro, meglio non riavviare per ora

[Rama]

credo di sì, forse ho tolto qualche spunta in .config pensando che fossero cose che non mi servissero;
vabbè, fra qualche giorno riavvierò e sa va con il kernel d'installazione confronterò i due .config;

[idefix]

fa parte di gcc, ma magari gwenviev
cerca una libreria che hai con un nome leggermente diverso
e manca solo un link simbolico.

es: cerca libgomp.so.1 che in realta è solo un link a libgomp.so.1.0.0

[Rama]

sì, è così, ci sono entrambi;
dei link simbolici fo largo uso, ad esempio per far funzionare amule, malgrado i puristi storcano il naso;
qui la questione mi sembra diversa, è come se se il gcc che ho su questo kernel 6.0.7 non sia lo stesso che ha compilato il pacchetto della 15 ufficiale, ma per compilare il 6.0.7 ho usato proprio quello, non ho mica installato un gcc nuovo;
ci capisco poco e riporto un'altra stranezza, stavo impazzendo per far andare Virtualbox: si installava ma poi dava errori, ho messo la versione più recente, la 7.0.2 r154219 (Qt5.15.2), e va liscia -mentre le versioni precedenti non giravano con tutti e due i kernel;
vabbè, domani riavvierò e vedrò se gwenviev va con il kernel ufficiale della 15, ormai sono tre giorni e sette ore che la macchina è su e quindi il problema dei blocchi doveva essere causato dall'ups che ho rottamato;

[idefix]

hai usato anche le stesse glibc ?

[Rama]

forse, vedo che ho aggiornato
glibc-zoneinfo-2022f-noarch-1_slack15.0.txz
penso dopo aver compilato il kernel, momento... no, il kernel è del 4, mentre l'aggiornamento è dell'8;
vabbè, provo a riavviare;
...
non va lo stesso;

[joe]

La risposta breve secondo me è la seguente:
se aggiorni le "glibc", su cui si reggono quasi tutti i pacchetti del sistema... o aggiorni anche tutti gli altri pacchetti, in pratica sincronizzando il parco software locale con quello ufficiale, oppure va tutto a... ramengo.

In ogni caso Il kernel non c'entra nulla con gwenview. Puoi aggiornare tutto il sistema, poi ricompilarti il kernel come vuoi e nella versione che preferisci... e gwenview deve ancora funzionare. In questo caso il Gwenview che hai sul sistema, probabilmente era stato prodotto compilandolo "contro" una versione di glibc diversa (più vecchia, proprio quella che avevi in precedenza) da quella che hai aggiornato ora, più recente quindi.
Tu aggiorni glibc ed tutto quello che dipendeva dalla vecchia versione di gcc potenzialmente non gira più. Dico potenzialmente perché poi di solito molta roba funziona ancora, o in alcuni casi potrebbe funzionicchiare.

Per buona norma quando fai un aggiornamento di roba ufficiale, conviene aggiornare tutto.
Se tutto è coerente, ovvero se tutto è sincronizzato al repo ufficiale "attuale", è più difficile cadere in errori e complicazioni del genere.
L'operazione più problematica resta rendere coerenti col sistema aggiornato anche i pacchetti di terze parti quindi extraufficiali, sia precompilati tipo da alien o altri repo terzi, sia prodotti in locale compilando da sorgenti con slacbuilds per esempio di SBo o anche creati a mano in proprio.

Quando fai un aggiornamento del sistema, ecco che in teoria dovresti ricreare e aggiornare anche i pacchetti compilati in locale, e se ne hai tanti non è un'operazione banale e veloce.

Questo discorso è tanto più vero quanto più si stia considerando aggiornamento di pacchetti fondamentali come gcc glibc ecc ecc... roba su cui appunto poggiano tutte le librerie e le altre applicazioni.

[Rama]

ok, scarico il sorgente e lo compilo;

[erio]

Ma a che serve se hai Slackware 15 non puoi cambiare le glibc e la versione delle GCC non cambia come la current quando accade, se hai tutto installato KDE deve andare senza intoppi caso mai se hai il vecchio kernel rimettilo per controllo, ma posso sbagliare

[joe]

In realtà non erano le glibc, il pacchetto aggiornato come si vede anche dal changelog del ramo stable era "glibc-zoneinfo-2022f-noarch-1_slack15.0.txz".

Codice: Seleziona tutto

+--------------------------+
Tue Nov 8 22:21:43 UTC 2022
patches/packages/glibc-zoneinfo-2022f-noarch-1_slack15.0.txz: Upgraded.
       This package provides the latest timezone updates.

Al ché credo si possa anche escludere che il problema sia quell'aggiornamento, tantomeno il cambio di kernel.
Gwenview lamenta quell'errore riportato in cima e direi che si debba partire da lì per capire quali modifiche Rama ha apportato al sistema per provocare quell'errore.

Se per qualche motivo avesse compilato una libreria coinvolta nelle dipendenze di gwenview, dopo quello non la trova più nella versione a cui era collegato, tanto per fare un esempio.
Ma magari il problema è un altro, in ogni caso si deve partire dall'errore che viene stampato al lancio di gwenview.

[Rama]

ho solo compilato il kernel;
che gwenviev non vada non è un gran problema, ci sono altri programmi per fare il poco che mi serve;
è solo curiosità di sapere perché non va;
pensavo potesse dipendere da qualcosa che ho tolto nel .config ma non va neanche col kernel d'installazione;

EDIT
reinstallando avevo fatto tutti gli aggiornamenti dal rilascio della 15 (avevo salvato i pacchetti) ma il sistema si era rivelato instabile quindi ho rifatto l'installazione e mi sono limitato a fare solo i più recenti:

file:///dati/INS + UP/glibc-zoneinfo-2022f-noarch-1_slack15.0.txz
file:///dati/INS + UP/mariadb-10.5.18-x86_64-1_slack15.0.txz
file:///dati/INS + UP/php-7.4.33-x86_64-1_slack15.0.txz
file:///dati/INS + UP/sysstat-12.7.1-x86_64-1_slack15.0.txz
file:///dati/INS + UP/xfce4-settings-4.16.4-x86_64-1_slack15.0.txz

[joe]

Il sistema dovrebbe o potrebbe con più probabilità rivelarsi instabile proprio se fai un mezzo aggiornamento. Pat rilascia il set ufficiale di aggiornamenti testati proprio per lavorare tutti insieme. Se tu hai installato un parco software non sincronizzato con quello ufficiale allora possono sorgere incongruenze e qualche dipendenza può non essere più soddisfatta.
Magari non tene accorgi per mesi, poi quando hai bisogno di usare quel certo programma che usi di rado, lo lanci e... magicamente non funziona.

In rete si trova anche la possibilità di incongruenze dovute all'installazione di un kernel nuovo con pacchetti compilati su un altro più vecchio che in qualche modo (al momento non ricordo più di preciso) hanno bisogno degli headers del vecchio kernel. Personalmente non ricordo di aver mai avuto problemi del genere nonostante abbia spesso usato kernel "alieni".
Però se dici che anche rimettendo il kernel d'installazione il problema persiste, meglio capire di quale pacchetto sono parte quei files:
- sia libgomp.so.1
- di cui controllare la versione (infatti diceva version `GOMP_4.5' not found)
- sia /usr/lib64/libraw.so.20 (anche di questo verificare che si tratti del file originale)

Aiutati con il motore di ricerca di ZeroUno:

slakfinder.org

Cerca per nome del file invece che per pacchetto.
Un'altra cosa: stiamo parlando di un ssitema 64bit liscio?
O di Multilib?

[Rama]

liscio, non ricordo di aver mai fatto il multilib;
l'aggiornamento doveva essere completo, solo che quando ci sono più aggiornamenti di un pacchetto tengo solo l'ultimo in /UP, può darsi che saltando un passaggio si creino problemi?

[joe]

Direi di no...
Lo faccio tanto di rado che non ricordo mai di preciso la procedura, ma se fai tipo un slackpkg upgrade-all dovresti vedere se ti propone degli aggiornamenti per i pacchetti in questione, puoi lanciarlo senza poi aggiornare effettivamente nulla, se ben ricordo salta fuori il menu in curses con i pacchetti da selezionare per l'aggiornamento.

Slackpkg can be used to upgrade the whole distribution.
The usual way is to do:

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system

Però occhio perché clean-system disinstalla tutto il software non ufficiale se ben ricordo.
Io farei "update" e "upgrade-all", il primo per sincronizzare il database locale dei pacchetti ufficiali col repo ufficiale remoto. Il secondo per dare un'occhiata agli aggiornamenti che vengono proposti, in particolare gcc, aaa-libraries e gli altri pacchetti coinvolti ovvero libgomp, libraw ed eventualmente anche gwenview (ma quest'ultimo non dovrebbe).

Per curiosità potresti anche postare l'out di alcuni comandi tipo:

Codice: Seleziona tutto

$ find / name -name libgomp.so.1 2>/dev/null|sort|cat -n

Codice: Seleziona tutto

$ grep libgomp.so.1 /var/log/packages/* 2>/dev/null|cut -f5- -d\/|cat -n

Codice: Seleziona tutto

$ grep libgomp.so.1 /var/log/packages/* 2>/dev/null | cut -f2 -d:|sed 's/^/\//' |xargs file|sort |cat -n

Col primo cerchi il file libgomp.so.1 nel filesystem, col secondo cerchi i pacchetti che lo contengono, il terzo è per vedere cosa sono effettivamente quei files.
La numerazione delle righe di output non guardarla tra il secondo e la terzo out.