Pierre Chifflier <[EMAIL PROTECTED]> writes: >[please CC me, I'm not subscribed] > > >For ex, the code 'use DBI;' results in an error: >jui 19 12:14:39 <thread -1225401424> <- 'SITE test' >/home/pollux/DEL/sbin/wzdftpd: symbol lookup error: >/usr/lib/perl5/auto/DBI/DBI.so: undefined symbol: Perl_Tstack_sp_ptr > > >I have tried many things without success, and I explained my efforts >in details here: >http://www.wzdftpd.net/wiki/index.php/Scripting_in_Perl#symbol_lookup_error > >I have put as many details as possible on this page, if something is >missing just tell me. > >To resume, the problem seems related to the fact that the interpreter >is created and contained in a shared library (.so), loaded via >dlopen(). The exact same code, linked differently in the program, >works perfectly.
Exactly. When a extension is loaded it looks for symbols in the compiled in dependant libraries and in the "root" executable. But the root is your main app not perl so doesn't export the perl symbols. The "easy" fix is to dlopen() your perl.so with RTLD_GLOBAL in the flags argument when you load it into your main application. See dlopen() docs. What (should) also work is explicitly linking perl extensions with -L/-R/-l options which will find you perl.so (OS runtime should then spot that your application already has that loaded and use it - but this part hasn't always worked right.) >what is weird is that this errors calls exit() directy, it does use >the standard perl error mechanism (and so aborting the entire program, >not only the perl interpreter). > >The C code causing the problem is simple: >val = eval_pv( "use DBI;", FALSE); > >The exact same code works if placed in a separate (standalone) >program, so I suspect a side effect. > >I am really hopping someone has run into this, any help would be much >appreciated. > >Thanks, >Pierre
