AFAICT, there are two problems:
the output of `perl -MExtUtils::Embed -e ccopts -e ldopts` (in particular the -lperl therein) is inserted too early on the command line. As the linker (ld) by default only searches once to satisfy externally referenced symbols, the perl library didn't get included.
when you load the shared lib using dlopen, you need to specify RTLD_GLOBAL (instead of RTLD_LOCAL), so the symbols will be made visible to any subsequently loaded libs, such as Data/Dumper/Dumper.so.
Here's how I got it to work on my Linux box (with Perl installed under /usr/local/perl/5.10.0):
# compile/link shared lib which includes Perl interpreter: gcc -Wall -pedantic -fPIC -shared \ -o perl_test1.so perl_test1.c \ `/usr/local/perl/5.10.0/bin/perl -MExtUtils::Embed -e ccopts -e ld +opts` # compile/link the test program that loads it using dlopen: gcc -Wall -pedantic -Wl,-rpath=. \ -o perl_test2 perl_test2.c \ -ldl # ...and run it: $ ./perl_test2 $VAR1 = 'this is a string';
In reply to Re: Problem with dlopen and shared objects using perl libs
by almut
in thread Problem with dlopen and shared objects using perl libs
by swehack
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |