slacky.eu

Sto compilando libproxy 0.4.0 (dipendenza di amsn) per slackware-current con kde 4.4.1
Al momento non ho una current pulita (cioè con kde 4.3.5), mentre la 13.0 non compila perchè libproxy vuole cmake 2.8 mentre la 13.0 ha la 2.6

Lancio "cmake ." e poi "make"
Ad un certo punto però si blocca con il messaggio:

Codice: Seleziona tutto

libmodman.so.0: undefined reference to `__dlclose'
libmodman.so.0: undefined reference to `__dlsym'
libmodman.so.0: undefined reference to `__dlerror'
libmodman.so.0: undefined reference to `__dlopen'
collect2: ld returned 1 exit status

Ho visto che il comando che fallisce è:

Codice: Seleziona tutto

cd libmodman && /usr/bin/c++   -g -Wall -Werror -fvisibility=hidden    CMakeFiles/builtin.dir/test/builtin.cpp.o CMakeFiles/builtin.dir/libmodman/test/builtin_one.cpp.o  -o builtin -rdynamic libmodman.so.0 -ldl -Wl,-rpath,/root/libproxy-0.4.0/libmodman

Da un "strace -f" scopro che cerca, invano, libdl.so
effettivamente non so perchè in /lib non è stato creato il link "libdl.so -> libdl.so.2"
Poco male.. lo creo e aggiungo -L/lib alla riga, ma non cambia niente. Il messaggio è lo stesso, nonostante strace -f mi dice che libdl.so ora l'ha trovato.
libdl è 2.11.1 dalle glibc-solibs della current

Che cosa manca?

Ciao
01

masalapianta ha scritto:-ldl

guarda bene che già c'è.

piuttosto mi chiedo che versione di libdl vuole, per nei makevile, cmakefile ecc non sono riuscito a vederlo.

Ciao
01

in una current pulita mi si blocca per -lmozjs
ho solo seamonkey, e sembrerebbe tutto ok, solo che vedo che dice che il comando seamonkey-js non c'è, in effetti c'è solo il file per pkgconfig, ma vedo che anche per debian è così per esempio, anche se in debian c'è libmozjs presa da xulrunner

per glibc non da errori

ZeroUno ha scritto:
masalapianta ha scritto:-ldl
guarda bene che già c'è.

piuttosto mi chiedo che versione di libdl vuole, per nei makevile, cmakefile ecc non sono riuscito a vederlo.

Ciao
01

comunque libproxy.so la crea

Codice: Seleziona tutto

# ldd libproxy.so.1.0.0
        linux-gate.so.1 =>  (0xffffe000)
        libmodman.so.0.0.0 => /tmp/pkg/libproxy-0.4.0/libmodman/libmodman.so.0.0.0 (0xb772e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb76e9000)
        libdl.so.2 => /lib/libdl.so.2 (0xb76e5000)
        libmozjs.so => /usr/lib/seamonkey-2.0.3/libmozjs.so (0xb75ee000)
        libplds4.so => /usr/lib/seamonkey-2.0.3/libplds4.so (0xb75ea000)
        libplc4.so => /usr/lib/seamonkey-2.0.3/libplc4.so (0xb75e6000)
        libnspr4.so => /usr/lib/seamonkey-2.0.3/libnspr4.so (0xb75b3000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb74c6000)
        libm.so.6 => /lib/libm.so.6 (0xb74a0000)
        libc.so.6 => /lib/libc.so.6 (0xb7341000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7323000)
        /lib/ld-linux.so.2 (0xb7763000)

ok. metto in piedi una current e vedo.

chissà perchè non veniva creato il link /usr/lib/libdl.so -> /lib/libdl.so.2
e quello che avevo creato io era in /lib mentre veniva cercato in /usr/lib

Ora devo risolvere il problema di mozjs (odio cmake).

lanciando "make VERBOSE=1" noto che fallisce

Codice: Seleziona tutto

cd utils && /usr/bin/gcc     CMakeFiles/proxy.dir/proxy.c.o  -o proxy -rdynamic ../lib/libproxy.so.1.0.0 ../libmodman/libmodman.so.0 -lm -lpthread -lmozjs -lplds4 -lplc4 -lnspr4 -lpthread -lmozjs -lplds4 -lplc4 -lnspr4 -ldl -Wl,-rpath,/root/Downloads/amsnbuild/libproxy/libproxy-0.4.0/lib:/root/Downloads/amsnbuild/libproxy/libproxy-0.4.0/libmodman:

aggiungendo a mano "-L/usr/lib/seamonkey" invece va a buon fine.

Ciao
01

la cosa curiosa è che il -L/usr/lib/seamonkey lo mette in automatico su tanti gcc (find -name link.txt) mentre non lo mette lì dove serve.

Ciao
01

ZeroUno ha scritto:la cosa curiosa è che il -L/usr/lib/seamonkey lo mette in automatico su tanti gcc (find -name link.txt) mentre non lo mette lì dove serve.

infatti alcune librerie le crea con i vari flag corretti, tranne quella interessata
vedo che le altre distribuzioni però hanno ancora libproxy 2.3, chissà se il motivo è solamente cmake
tra l'altro alcune compilano con --without-mozjs

ma a cosa serve a amsn? io lo compilo tranquillamente senza
ad usare il proxy?

conraid ha scritto:tra l'altro alcune compilano con --without-mozjs

beh, con cmake non saprei come fare.

comunque ho scaricato la versione current di libproxy, ma le cose non cambiano.
mi sa che mi devo vedere bene cmake.

ma a cosa serve a amsn? io lo compilo tranquillamente senza
ad usare il proxy?

a detta degli slack-required di slacky è una dipendenza di libsoup.

ecco i dettagli delle dipendenze e l'ordine di compilazione:
tls => none.
gst-python => none
libproxy => none
orbit2 => none
gconf => orbit2
libsoup => gconf,libproxy
gssdp => libsoup
gupnp => gssdp
gupnp-igd => gupnp
libnice => gupnp-igd
farsight2 => libnice,gst-python
amsn => suggested before compile: FARSIGHT2 and GSTREAMER (per l'audio),GUPNP-IGD; suggested after compile: TLS

Ciao
01

capito, io compilo senza upnp, mi sta sulle palle quella tecnologia

conraid ha scritto:capito, io compilo senza upnp, mi sta sulle palle quella tecnologia

io semplicemente (di solito) compilo con gli slackbuild di slacky

comunque vedendomi un po' di struttura del cmake, se cambio dentro CMakeLists.txt la variabile ${CMAKE_CXX_FLAGS}, questa viene riportata su tutti i link.txt, ma non su quello incriminato. Il che significa che oltre alle librerie mozjs non ci va nemmeno:
-g -Wall -Werror -fvisibility=hidden -Os

Ciao
01

slacky.eu

undefined reference to `__dlclose'

undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'

Re: undefined reference to `__dlclose'