Ho un codice C++ 14 che dovrebbe caricare un file oggetto arbitrario condiviso con dlopen
. Sfortunatamente su alcuni sistemi (ad esempio il mio archlinux, si dice che si applichi anche ad alcuni .so su ubuntu e gentoo), questi so-file possono essere "GNU ld scripts" invece dei binari reali.Caricamento di GNU ld script con dlopen
Per riferimento, ecco il contenuto del mio /usr/lib/libm.so
:
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP (/usr/lib/libm.so.6 AS_NEEDED (/usr/lib/libmvec.so.1))
ho trovato un paio di code-pezzi che si occupano di questo problema in ghc o ruby. Vorrei evitare di ricorrere all'analisi manuale del file di testo basato sull'analisi del testo dlerror
e del file. Sento che è terribilmente malvagio e non sarò in grado di implementare e gestire casi angolari di questo formato.
Esiste un modo pulito per implementare la gestione di questo caso? Francamente sono perplesso sul motivo per cui dlopen
in realtà non gestisce questi passaggi.
Nota: Considerando le patch summenzionate, penso che questo non sia semplicemente un problema con la configurazione/le versioni del mio sistema. Se questo dovrebbe funzionare immediatamente con dlopen
(bug invece di funzionalità mancante), per favore fatemelo sapere.
Il tuo ld.so è abbastanza recente? – marcolz
Non correlato a una lingua specifica, ma al caricamento/collegamento. – Olaf
@Olaf Sto cercando una soluzione che possa essere utilizzata nel mio programma C++. Dal momento che sto caricando la libreria durante il runtime usando il codice C++/C, la considero correlata. – Zulan