LD_LIBRARY_PATH [RISOLTO]
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware 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 Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
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 sempre la versione di Slackware 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 Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
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.
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
LD_LIBRARY_PATH [RISOLTO]
Per l'installazione di alcuni pacchetti è raccomandato l'impostazione della variabile d'ambiente LD_LIBRARY_PATH per includervi un determinato path. Di solito quando devo impostare una variabile d'ambiente che non sia temporanea lo faccio in /etc/profile oppure in .bashrc, ma non ho idea di come fare con LD_LIBRARY_PATH e non vorrei fare pasticci: ldconfig funziona regolarmente e presumo che abbia nella sua configurazione il percorso predefinito /usr/lib64 (e forse anche /usr/local/lib64), però non riesco a capire dove sia impostata questa variabile:
- in /etc/profile non c'è nulla in proposito
- il comando # echo $LD_LIBRARY_PATH restituisce una stringa vuota, sia che lo lanci da konsole dopo su, sia che lo lanci da una sessione root aperta in un terminale
- la directory /etc/ld.so.conf.d è vuota: ho letto che altri percorsi dovrebbero essere aggiunti nel file /etc/ld.so.conf.d/.conf, ma questo file non esiste, peraltro non so quale sarebbe la sintassi corretta, ammesso che in Slackware si possa usare questo metodo
In teoria potrei impostare qualcosa tipo export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/share/vattelapesca/lib ma dal momento che echo $LD_LIBRARY_PATH restituisce una stringa vuota, non vorrei che il comando sovrascrivesse la variabile d'ambiente resettando i valori già impostati.
Un altra via potrebbe essere quella di aggiungere il percorso come variabile temporanea nello slackbuild di una compilazione, ma ammesso che funzioni, credo che questo sarebbe attivo solo ai fini della compilazione, ma non so se poi il percorso di una libreria viene "ereditato" stabilmente nell'installazione qualora dovesse servire anche in runtime.
In sostanza, cosa devo fare per includere stabilmente un ipotetico percorso /usr/share/vattelapesca/lib in LD_LIBRARY_PATH?
- in /etc/profile non c'è nulla in proposito
- il comando # echo $LD_LIBRARY_PATH restituisce una stringa vuota, sia che lo lanci da konsole dopo su, sia che lo lanci da una sessione root aperta in un terminale
- la directory /etc/ld.so.conf.d è vuota: ho letto che altri percorsi dovrebbero essere aggiunti nel file /etc/ld.so.conf.d/.conf, ma questo file non esiste, peraltro non so quale sarebbe la sintassi corretta, ammesso che in Slackware si possa usare questo metodo
In teoria potrei impostare qualcosa tipo export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/share/vattelapesca/lib ma dal momento che echo $LD_LIBRARY_PATH restituisce una stringa vuota, non vorrei che il comando sovrascrivesse la variabile d'ambiente resettando i valori già impostati.
Un altra via potrebbe essere quella di aggiungere il percorso come variabile temporanea nello slackbuild di una compilazione, ma ammesso che funzioni, credo che questo sarebbe attivo solo ai fini della compilazione, ma non so se poi il percorso di una libreria viene "ereditato" stabilmente nell'installazione qualora dovesse servire anche in runtime.
In sostanza, cosa devo fare per includere stabilmente un ipotetico percorso /usr/share/vattelapesca/lib in LD_LIBRARY_PATH?
Ultima modifica di gian_d il dom 23 feb 2020, 10:31, modificato 1 volta in totale.
- marlavo
- Linux 1.x
- Messaggi: 180
- Iscritto il: ven 2 lug 2010, 16:38
- Nome Cognome: Marco Lavorini
- Slackware: 15.0 x86_x64
- Kernel: 6.6.21
- Desktop: XFCE 4.18
Re: LD_LIBRARY_PATH
Sulla 14.2 puoi usare "/etc/ld.so.conf ".
Nel mio troviamo:
Sulla current non ho verificato ma se esiste una directory "/etc/ld.so.conf.d/", basta che crei un file "pippo.conf" con dentro i path che ti interessano e successivamente dai un "ldconfig" come root.
Non ho provato ma dovrebbe funzionare
Vedi anche questa discussione: https://unix.stackexchange.com/question ... v-variable
Nel mio troviamo:
Codice: Seleziona tutto
cat /etc/ld.so.conf
/lib64
/usr/lib64
/usr/local/lib64
/usr/x86_64-slackware-linux/lib64
/usr/lib64/seamonkey
Non ho provato ma dovrebbe funzionare
Vedi anche questa discussione: https://unix.stackexchange.com/question ... v-variable
- ponce
- Iper Master
- Messaggi: 3026
- Iscritto il: mer 5 mar 2008, 16:45
- Nome Cognome: Matteo Bernardini
- Slackware: slackware64-current
- Kernel: 6.6.16
- Desktop: lxde
- Località: Pisa
- Contatta:
Re: LD_LIBRARY_PATH
Potresti fare l'esempio pratico di un software che te lo richiede?
A me è successo principalmente con software precompilati e ho risolto con un wrapper (ti faccio vedere come nell'ambito dell'esempio).
Sconsiglio vivamente /etc/ld.so.conf e affini perché valgono per qualunque cosa nel sistema operativo e porterebbero ad effetti indesiderati, mentre quello di cui mi sembra tu abbia bisogno è un "override" specifico per un'applicazione.
A me è successo principalmente con software precompilati e ho risolto con un wrapper (ti faccio vedere come nell'ambito dell'esempio).
Sconsiglio vivamente /etc/ld.so.conf e affini perché valgono per qualunque cosa nel sistema operativo e porterebbero ad effetti indesiderati, mentre quello di cui mi sembra tu abbia bisogno è un "override" specifico per un'applicazione.
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: LD_LIBRARY_PATH
Allora, per quel che mi riguarda di specifico il il software interessato è cudatoolkit e qtwpolar.ponce ha scritto: ↑ven 21 feb 2020, 10:08Potresti fare l'esempio pratico di un software che te lo richiede?
A me è successo principalmente con software precompilati e ho risolto con un wrapper (ti faccio vedere come nell'ambito dell'esempio).
Sconsiglio vivamente /etc/ld.so.conf e affini perché valgono per qualunque cosa nel sistema operativo e porterebbero ad effetti indesiderati, mentre quello di cui mi sembra tu abbia bisogno è un "override" specifico per un'applicazione.
Per quanto riguarda il primo, al termine della configurazione prima della compilazione compare questo messaggio:
Codice: Seleziona tutto
Please make sure that
- PATH includes /usr/share/cuda/bin
- LD_LIBRARY_PATH includes /usr/share/cuda/lib, or, add /usr/share/cuda/lib to /etc/ld.so.conf and run ldconfig as root
Per quanto riguarda qtwpolar, non riesco più a compilarlo da novembre, probabilmente deve essere cambiato qualcosa con l'aggiornamento di qwt: durante la compilazione mi compaiono due generi di errore. Il primo è che lo slackbuild non trova gli header di qwt in fase di configurazione, però ho risolto con una patch indicandogli esplicitamente il percorso /usr/include/qwt con una variabile INCLUDEPATH, il secondo, invece consiste in una lunga lista di errori generati da ld durante la compilazione. Nel file INSTALL del sorgente c'è scritto questo:
Codice: Seleziona tutto
If you have installed a shared library it's path has to be known to
the run-time linker of your operating system. On Linux systems read
"man ldconfig" ( or google for it ). Another option is to use
the LD_LIBRARY_PATH (on some systems LIBPATH is used instead, on MacOSX
it is called DYLD_LIBRARY_PATH) environment variable.
If you only want to check the QwtPolar examples without installing something,
you can set the LD_LIBRARY_PATH to the lib directory
of your local build.
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: LD_LIBRARY_PATH
PS: se serve posso inserire l'output degli errori generati da ld durante la compilazione di qwtpolar, ma non credo sia necessario. Il problema dipende sicuramente da quanto è riportato in INSTALL
- ponce
- Iper Master
- Messaggi: 3026
- Iscritto il: mer 5 mar 2008, 16:45
- Nome Cognome: Matteo Bernardini
- Slackware: slackware64-current
- Kernel: 6.6.16
- Desktop: lxde
- Località: Pisa
- Contatta:
Re: LD_LIBRARY_PATH
quale versione di cudatoolkit hai installato? hai usato uno SlackBuild o il pacchetto distribuito da nvidia? su slackware 14.2 o current?gian_d ha scritto: ↑ven 21 feb 2020, 12:14Allora, per quel che mi riguarda di specifico il il software interessato è cudatoolkit e qtwpolar.ponce ha scritto: ↑ven 21 feb 2020, 10:08Potresti fare l'esempio pratico di un software che te lo richiede?
A me è successo principalmente con software precompilati e ho risolto con un wrapper (ti faccio vedere come nell'ambito dell'esempio).
Sconsiglio vivamente /etc/ld.so.conf e affini perché valgono per qualunque cosa nel sistema operativo e porterebbero ad effetti indesiderati, mentre quello di cui mi sembra tu abbia bisogno è un "override" specifico per un'applicazione.
Per quanto riguarda il primo, al termine della configurazione prima della compilazione compare questo messaggio:La compilazione si completa regolarmente, ma saltano fuori problemi con il software che lo richiede come dipendenza. Opencv va in errore, non so se dipende da questo, con Blender la compilazione non ne viene inficiata, però non viene integrato il supporto a CUDA.Codice: Seleziona tutto
Please make sure that - PATH includes /usr/share/cuda/bin - LD_LIBRARY_PATH includes /usr/share/cuda/lib, or, add /usr/share/cuda/lib to /etc/ld.so.conf and run ldconfig as root
in questo senso potrebbe essere utile contattare il maintainer di cudatoolkit su SBo, che e' un utente di questo forum.
potrebbe aiutare anche se tu incollassi l'errore di opencv (se non sei sicuro di quale sia incollane un bel pezzo su pastebin.com o simili).
comunque, guardando lo SlackBuild su SBo che aggiunge solo qualcosa alla variabile d'ambiente $PATH, non sembra che che ci sia bisogno di specificare $LD_LIBRARY_PATH.
se usi current io ho testato la compilazione sia di qwt e qwt-polar e qui funzionano entrambi, il solo qwt ha bisogno di una piccola modifica allo SlackBuild: credo che nemmeno in questo caso sia rilevante impostare $LD_LIBRARY_PATH.Per quanto riguarda qtwpolar, non riesco più a compilarlo da novembre, probabilmente deve essere cambiato qualcosa con l'aggiornamento di qwt: durante la compilazione mi compaiono due generi di errore. Il primo è che lo slackbuild non trova gli header di qwt in fase di configurazione, però ho risolto con una patch indicandogli esplicitamente il percorso /usr/include/qwt con una variabile INCLUDEPATH, il secondo, invece consiste in una lunga lista di errori generati da ld durante la compilazione. Nel file INSTALL del sorgente c'è scritto questo:Premesso che non so a quale libreria condivisa si riferisca (non so se qwt o qt5, anche se l'errore compare durante la compilazione del supporto a qt4) in ogni modo gran parte di quello che c'è scritto in man ldconfig è fuori dalla mia portata di comprensione, quindi ci ho rinunciato. Per ora c'è installato un pacchetto di qwtpolar compilato prima di novembre, quanto basta per permettermi di installare comunque Qgis, che lo richiede come dipendenza necessaria.Codice: Seleziona tutto
If you have installed a shared library it's path has to be known to the run-time linker of your operating system. On Linux systems read "man ldconfig" ( or google for it ). Another option is to use the LD_LIBRARY_PATH (on some systems LIBPATH is used instead, on MacOSX it is called DYLD_LIBRARY_PATH) environment variable. If you only want to check the QwtPolar examples without installing something, you can set the LD_LIBRARY_PATH to the lib directory of your local build.
- conraid
- Staff
- Messaggi: 13630
- Iscritto il: gio 14 lug 2005, 0:00
- Nome Cognome: Corrado Franco
- Slackware: current64
- Desktop: kde
- Località: Livorno
- Contatta:
Re: LD_LIBRARY_PATH
Per cuda devi usare una soluzione come adottata dal pacchetto su SBo , anche se non è compilato ma è un'installazione del pacchetto di nvidia,
a quel punto hai le librerie nei posti richiesti.
stessa cosa per gli incude, ma non conosco cudatoolkit, tantomeno la sua compilazione (ma vedo che anche altre distro usano il run, che di solito nvidia rilascia come già compilati, non sorgenti, ma alzo le mani su questo che non ho mai provato).
Come ti dice ponce ld_library_path lo usi quando serve qualcosa per un'applicazione, tipo quelle che hanno bisogno di librerie diverse da quelle sistema, etc... e lanci con
al che lui cerca le librerie in quel percorso, si faceva con skype a suo tempo per esempio, ma ci sono varie app che han bisogno di trucchi simili, stessa cosa per la path di bin, e da SBo vedo infatti che cuda parte con un wrapper
Codice: Seleziona tutto
# Put libraries in the standard place
mkdir -p $PKG/usr/lib${LIBDIRSUFFIX}
mv $PKG/usr/share/cuda/lib${LIBDIRSUFFIX} $PKG/usr
cd $PKG/usr/share/cuda
ln -sf ../../lib${LIBDIRSUFFIX} lib${LIBDIRSUFFIX}
stessa cosa per gli incude, ma non conosco cudatoolkit, tantomeno la sua compilazione (ma vedo che anche altre distro usano il run, che di solito nvidia rilascia come già compilati, non sorgenti, ma alzo le mani su questo che non ho mai provato).
Come ti dice ponce ld_library_path lo usi quando serve qualcosa per un'applicazione, tipo quelle che hanno bisogno di librerie diverse da quelle sistema, etc... e lanci con
Codice: Seleziona tutto
LD_LIBRARY_PATH="/PATHLIB" nomeapplicazione
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: LD_LIBRARY_PATH
OK, proverò così, allora
- brg
- Linux 3.x
- Messaggi: 580
- Iscritto il: sab 12 mar 2011, 14:20
- Slackware: 15.0
- Kernel: 5.15.117
- Desktop: KDE5
- Località: Montecatini
- Contatta:
Re: LD_LIBRARY_PATH
Per le librerie BLAS/LAPACK di AMD ho fatto così:
Codice: Seleziona tutto
bash-4.3$ cat .bashrc
# ACML
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/acml5.3.1/gfortran64_fma4_mp/lib
export LD_LIBRARY_PATH
export ACML_FAST_MALLOC=1
# LIBGL 32 bit
#export LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/dri/:/usr/lib64/xorg/modules/dri/
#alias
alias grep='grep --color=auto'
alias ls='ls --color=auto'
#DocBook
export SP_CHARSET_FIXED=YES
export SP_ENCODING=XML
#SDL
export SDL_VIDEO_FULLSCREEN_DISPLAY=0
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: LD_LIBRARY_PATH
Anch'io avevo pensato alla soluzione più semplice, ovvero integrare i percorsi non standard nella variabile d'ambiente usando .bashrc, tuttavia non mi convince per un fatto strano: il comando echo $LD_LIBRARY_PATH mi restituisce una stringa vuota, ma è evidente che la variabile d'ambiente non può essere vuota. Detto questo, non vorrei che impostando un comando tipo
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/nuovopath
la variabile d'ambiente viene modificata sostituendo integralmente /nuovopath al suo valore attuale invece di aggiungerlo
È vero che se qualcosa non dovesse funzionare si può comunque rimuovere l'impostazione da .bashrc, ma nello stesso tempo non mi fido a fare un'operazione di cui non sono certo delle possibili conseguenze. Per ora applicherò la soluzione indicatami da Conraid, per cudatoolkit si può sicuramente fare, per qwtpolar penso dovrò usare il metodo indicato da ponce, ma devo però capire qual è la dipendenza che genera il problema, dal momento che dall'output della compilazione non si evince
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/nuovopath
la variabile d'ambiente viene modificata sostituendo integralmente /nuovopath al suo valore attuale invece di aggiungerlo
È vero che se qualcosa non dovesse funzionare si può comunque rimuovere l'impostazione da .bashrc, ma nello stesso tempo non mi fido a fare un'operazione di cui non sono certo delle possibili conseguenze. Per ora applicherò la soluzione indicatami da Conraid, per cudatoolkit si può sicuramente fare, per qwtpolar penso dovrò usare il metodo indicato da ponce, ma devo però capire qual è la dipendenza che genera il problema, dal momento che dall'output della compilazione non si evince
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: LD_LIBRARY_PATH
bah... mi stavo mettendo un problema che non esiste: con ldconfig -p ho verificato che le librerie sono regolarmente linkate perché installate in /usr/lib64. Anche gli header sono installati nella directory /usr/include. Insomma, è già stato previsto tutto dal mantainer dello slackbuild, semplicemente mi aveva tratto in inganno il messaggio dato dall'installazione del pacchetto originario nella struttura del pacchetto tgz in /tmp/SBo che, ovviamente non ha alcuna relazione con le impostazioni date successivamente dallo slackbuild.conraid ha scritto: ↑ven 21 feb 2020, 12:50Per cuda devi usare una soluzione come adottata dal pacchetto su SBo , anche se non è compilato ma è un'installazione del pacchetto di nvidia,
a quel punto hai le librerie nei posti richiesti.Codice: Seleziona tutto
# Put libraries in the standard place mkdir -p $PKG/usr/lib${LIBDIRSUFFIX} mv $PKG/usr/share/cuda/lib${LIBDIRSUFFIX} $PKG/usr cd $PKG/usr/share/cuda ln -sf ../../lib${LIBDIRSUFFIX} lib${LIBDIRSUFFIX}
Per qwtpolar vedrò più avanti, ora mi dedico ad altri aggiornamenti dal momento che comunque l'installazione di Qgis non è inficiata dalla presenza del vecchio pacchetto.
Grazie per l'aiuto e chiedo scusa perché potevo risparmiarvi questa richiesta
- ponce
- Iper Master
- Messaggi: 3026
- Iscritto il: mer 5 mar 2008, 16:45
- Nome Cognome: Matteo Bernardini
- Slackware: slackware64-current
- Kernel: 6.6.16
- Desktop: lxde
- Località: Pisa
- Contatta:
Re: LD_LIBRARY_PATH [RISOLTO]
comunque se stai usando lo SlackBuild su SBo spero tu sia su un'installazione della 14.2, perche' su current non funziona, nel senso che quella versione del cudatoolkit richiede al massimo il gcc-5.x mentre current ne ha uno molto piu' recente: e' uno dei motivi per cui ti avevo consigliato di sentire il maintainer, nel caso ne avesse una versione piu' aggiornata.
-
- Linux 3.x
- Messaggi: 654
- Iscritto il: mer 16 lug 2014, 17:35
- Nome Cognome: Giancarlo Dessì
- Slackware: 64 current
- Kernel: 6.6.xx
- Desktop: KDE 5.27
- Località: Sardinia
- Contatta:
Re: LD_LIBRARY_PATH [RISOLTO]
Lo slackbuild è quello rilasciato nel tuo repository, non uso più quelli di SBo da parecchio tempo, forse più di un anno, da quando mi avevi segnalato l'esistenza del tuo repository. Per quanto riguarda il compilatore, il problema della versione saltava fuori per la compilazione delle librerie Deep Neural Network (CuDNN) con l'installazione di una versione successiva a quella supportata dallo slackbuild (sempre del tuo repository), ma il problema l'avevo superato usando proprio quel compilatore, dato che ce l'ho installato perché mi serve per la compilazione di pdftk.
Detto questo, qualche problema c'è sicuramente: nel sistema sono installati sia cudatoolkit sia le librerie CuDNN, però sono installazioni svincolate da tutto il resto perché a suo tempo non sono riuscito a integrarne il supporto su opencv e su blender. Avendo altre priorità da sbrigare l'avevo accantonato mesi fa, ora sto accingendomi ad affrontarlo perché sto aggiornando un po' tutti i pacchetti che più o meno direttamente sono collegati alle qt5, dopo l'aggiornamento di questa libreria alla 5.13.2 (compreso, quindi, opencv).
Vado molto a rilento perché la "manutenzione" del sistema con gli aggiornamenti del software è subordinata a mantenerne la funzionalità in produzione dal momento che l'installazione della current è sul pc che uso nell'ordinarietà. Conservo una copia di tutti i pacchetti che riesco a compilare, anche di differenti versioni, ma installo solo le versioni che mi permettono di mantenere funzionale tutto il software dipendente. All'occorrenza, quando mi ritrovo un po' di tempo libero, allora mi dedico al testing per aggiornare a versioni più recenti o aggiungere il supporto a funzionalità aggiuntive nel software già installato. Se ci riesco bene altrimenti ritorno all'ultima configurazione funzionante.
In definitiva, quindi, non ho un'estrema necessità di avere un supporto a Cuda. È solo in una prospettiva a medio termine perché la prossima estate vorrei dedicarmi a conoscere un po' di deep learning nel contesto del 3D e avendo una scheda Nvidia penso che il framework potrebbe essermi molto utile. D'altra parte questo obiettivo non deve interferire con quello che faccio tutti i giorni con il computer, sia per intrattenimento sia per lavoro sia per "studio".
Detto questo, qualche problema c'è sicuramente: nel sistema sono installati sia cudatoolkit sia le librerie CuDNN, però sono installazioni svincolate da tutto il resto perché a suo tempo non sono riuscito a integrarne il supporto su opencv e su blender. Avendo altre priorità da sbrigare l'avevo accantonato mesi fa, ora sto accingendomi ad affrontarlo perché sto aggiornando un po' tutti i pacchetti che più o meno direttamente sono collegati alle qt5, dopo l'aggiornamento di questa libreria alla 5.13.2 (compreso, quindi, opencv).
Vado molto a rilento perché la "manutenzione" del sistema con gli aggiornamenti del software è subordinata a mantenerne la funzionalità in produzione dal momento che l'installazione della current è sul pc che uso nell'ordinarietà. Conservo una copia di tutti i pacchetti che riesco a compilare, anche di differenti versioni, ma installo solo le versioni che mi permettono di mantenere funzionale tutto il software dipendente. All'occorrenza, quando mi ritrovo un po' di tempo libero, allora mi dedico al testing per aggiornare a versioni più recenti o aggiungere il supporto a funzionalità aggiuntive nel software già installato. Se ci riesco bene altrimenti ritorno all'ultima configurazione funzionante.
In definitiva, quindi, non ho un'estrema necessità di avere un supporto a Cuda. È solo in una prospettiva a medio termine perché la prossima estate vorrei dedicarmi a conoscere un po' di deep learning nel contesto del 3D e avendo una scheda Nvidia penso che il framework potrebbe essermi molto utile. D'altra parte questo obiettivo non deve interferire con quello che faccio tutti i giorni con il computer, sia per intrattenimento sia per lavoro sia per "studio".