On 29/07/2013 23:59, vincent guffens wrote: > Hi, > > In order to call scilab from python, I used to create a module that > links against libscilab.so. It turns out that this does not work anymore > althought linking against libscilab-cli.so still works (without graphics > obviously). > > It looks like the library is now empty as shown with nm below while the > same operation on libscilab-scli.so returns thousand of symbols. > > $ nm -D /usr/local/lib/scilab/libscilab.so > w _Jv_RegisterClasses > 0000200c A __bss_start > w __cxa_finalize > w __gmon_start__ > 0000200c A _edata > 00002014 A _end > 00000448 T _fini > 000002f0 T _init > > Is it an intented behaviour? Are the users supposed to link against all > the individual needed shared libraries? Actually, it depends how Scilab is built.
If it is built with --enable-maintainer-mode, each module will have it own shared library (.so). lld will show plenty of dependencies: $ ldd modules/.libs/libscilab-cli.so|wc -l 89 $ readelf -s modules/.libs/libscilab-cli.so|wc -l 68 However, if we are building Scilab without the argument --enable-maintainer-mode, it will build many modules as static library and link them into a single shared libraries. For example, when using the deb packages: $ ldd /usr/lib/scilab/libscilab-cli.so|wc -l 44 $ readelf -s /usr/lib/scilab/libscilab-cli.so|wc -l 4102 One way or the other, in the first case, the linker should do the job of loading the other libraries (ie -lscilab-cli or -lscilab should be enough ... or not ;) ) Sylvestre _______________________________________________ dev mailing list [email protected] http://lists.scilab.org/mailman/listinfo/dev
