Hi Manuel, Thank you for the response.
On Tue, Oct 6, 2015 at 2:28 AM, <[email protected]> wrote: > The multiple definitions are expected as the purpose to the bmem.so is > to be preloaded (LD_PRELOAD)! This probably means that very case, the > explicit dependency -lbigloo_s4.2a should not be added when building > bmem.so. I will check if that works on my machine (debian now) and if it > does I will modify the Makefile accordingly. Thank you, that does fix the problem for me. However, I hit another build failure: make[10]: Entering directory '/builddir/build/BUILD/bigloo4.2a/api/gstreamer/src' gcc -shared -o libbigloogstreamer_s-4.2a.so.0 \ -Wl,-soname=libbigloogstreamer_s-4.2a.so.0 \ -Wl,--enable-new-dtags,-rpath=/usr/lib64/bigloo/4.2a \ objs/bglgst.o objs/bglgst_thread.o objs/bglgst_portsrc.o objs/bglgst_portsink.o objs/bglgst_port.o objs/gstbin.o objs/gstbus.o objs/gstbuffer.o objs/gstcaps.o objs/gstelement.o objs/gstelementfactory.o objs/gstghostpad.o objs/gstmessage.o objs/gstobject.o objs/gstpipeline.o objs/gstpluginfeature.o objs/gstregistry.o objs/gstpad.o objs/gstpadtemplate.o objs/gstplugin.o objs/gstreamer.o objs/gsterror.o objs/gststructure.o objs/gsttypefind.o objs/gstparse.o objs/gstplugin_bglports.o objs/gstmm_music.o \ \ -Wl,--as-needed -lgc -L/builddir/build/BUILD/bigloo4.2a/lib/bigloo/4.2a \ -lgstaudio-0.10 -lgstbase-0.10 -lgstinterfaces-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -pthread -lgthread-2.0 -pthread -lglib-2.0 -lxml2 -lbigloopthread_s-4.2a -lbigloomultimedia_s-4.2a -lbigloo_s-4.2a -lgc-4.2a \ -lc && \ if [ "libbigloogstreamer_s-4.2a.so.0" != "/builddir/build/BUILD/bigloo4.2a/lib/bigloo/4.2a/libbigloogstreamer_s-4.2a.so.0" ]; then \ mv libbigloogstreamer_s-4.2a.so.0 /builddir/build/BUILD/bigloo4.2a/lib/bigloo/4.2a/libbigloogstreamer_s-4.2a.so.0; \ fi /usr/bin/ld: cannot find -lgc-4.2a collect2: error: ld returned 1 exit status I am configuring bigloo with --customgc=no. The definition of GCCLOSELIB in api/gstreamer/src/Makefile looks suspect to me. That definition is only correct if --customgc=yes, isn't it? Indeed, removing that line let the build finish successfully. Now I see some test failures. The first pthread test run has one failure: cond-expand...ok. make-thread...ok. thread-name...ok. thread-specific...ok. thread-start...ok. bind-exit...ok. mutex...ok. mutex2...ok. mutex3...ok. mutex3...ok. thread-yield...ok. thread-join1...ok. thread-join2...ok. thread-join3...ok. thread-join4...ok. mutex...ok. mutex-specific...ok. mutex-specific2...ok. mutex-state...ok. mutex-lock...ok. mutex-timed-lock...ok. mutex-timed-lock2...ok. mutex-lock4...ok. condition-variable...ok. condition-variable2...ok. condition-variable3...ok. condition-variable4...ok. condition-variable5...ok. current-exception-handler...ok. with-exception-handler...ok. raise...ok. raise2...ok. eval...*** ERROR:bigloo: `segmentation violation' exception -- raised error. ==> provided: [#(23)] expected: [23] All tests executed... 32 succeeded 1 failed (eval) And the second pthread test run has 3 failures: cond-expand...ok. make-thread...ok. thread-name...ok. thread-specific...ok. thread-start...ok. bind-exit...ok. mutex...ok. mutex2...ok. mutex3...ok. mutex3...ok. thread-yield...ok. thread-join1...ok. thread-join2...ok. thread-join3...ok. thread-join4...ok. mutex...ok. mutex-specific...ok. mutex-specific2...ok. mutex-state...error. ==> provided: [not-abandoned] expected: [unlocked] mutex-lock...error. ==> provided: [abandoned] expected: [locked] mutex-timed-lock...ok. mutex-timed-lock2...ok. mutex-lock4...ok. condition-variable...ok. condition-variable2...ok. condition-variable3...ok. condition-variable4...ok. condition-variable5...ok. current-exception-handler...ok. with-exception-handler...ok. raise...ok. raise2...ok. eval...*** ERROR:instantiate::pthread: Unknown class -- (instantiate::pthread (body (lambda () 23))) 1. &thread1043, 2. &thread1042, 3. &thread1039, 4. &thread1035, 5. &thread1036, 6. &thread1032, 7. &thread1027, error. ==> provided: [#(23)] expected: [23] All tests executed... 30 succeeded 3 failed (mutex-state mutex-lock eval) 8. &thread1025, 9. &thread1023, 10. &thread1021, And almost all of the openpgp tests failed like this: key-rsa-read...*** ERROR:#unspecified: Type "bint" expected, "cell" provided -- #unspecified error. ==> provided: [#(#t)] expected: [#t] That first pthread test failure, with the eval, happens on this statement: (eval '(library-load 'pthread)) GDB shows something interesting. I used a breakpoint to watch bigloo initialize itself as it starts up, and then saw this: (gdb) print symbol_mutex $1 = (obj_t) 0xd98fa0 (gdb) print &symbol_mutex $2 = (obj_t *) 0xb72428 <symbol_mutex> Then continue on, run the failing eval, and: 1:=> (eval '(library-load 'pthread)) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff367eb9f in bgl_bstring_to_symbol (name=0x1040f60) at Clib/csymbol.c:87 87 BGL_MUTEX_LOCK( symbol_mutex ); Missing separate debuginfos, use: dnf debuginfo-install libgcc-5.1.1-4.fc23.x86_64 (gdb) print &symbol_mutex $3 = (obj_t *) 0x7ffff3a8d448 <symbol_mutex> (gdb) print symbol_mutex $4 = (obj_t) 0x1a Any idea what happened there? Why did the address of symbol_mutex change? Anyway, that's all I have time for tonight. I'll try to debug these test failures a bit more tomorrow night. Regards, -- Jerry James http://www.jamezone.org/
