On Fri, Jul 21, 2006 at 08:15:45AM +0100, Nick Ing-Simmons wrote: > 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.
Thanks a lot ! Using RTLD_GLOBAL solved my problem. Now all I have to do is to check that it won't create problems, and that it works on all supported platforms (mainly BSDs) > > 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.) > Not sure I understand correctly this part. My link flags are: `perl -MExtUtils::Embed -e ldopts` which expands to: -Wl,-E -L/usr/local/lib /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lm -lpthread -lc -lcrypt Anyway, the RTLD_GLOBAL solution seems to work. Thanks, Pierre
