|
I am porting an application from IRIX to Linux. The
application uses perl5.005_003 and has embedded perl via XS into a dynamic
library that is loaded at run-time through a dlopen()/dlsym() call. The
application work fine on IRIX.
We built perl5.005_003 on Linux with basically all the
standard switches for a Linux build . The only thing we changed was the
install location. The perl interpreter itself works fine, it reads and
executes scripts and can load various Perl modules including dynamic
libraries.
However, our application embeds per in a dynamic library
that is loaded at runtime via dlopen. This causes problems when perl tries
to load a module that has a dynamic library (such as IO). For some reason,
you get a unresolved symbol PL_sv_undef.
I reduced the test case to a simple program that dlopens
a so that has a simple interface to embedded perl. This has the same
problem. If I change the simple program so that it links with the so
directly, everything works fine. The symbol is defined in libperl.a as a
defined common uninitialized global symbol. The so I built, has it a defined but
unitialized and IO.so has it as undefined. Everything should bind to the
symbol in my so, but when this so is loaded at run time through dlopen() it
fails to bind.
Any ideas, I have no idea why this is happening?
I've tried to look at the Perl code but there are so many if blocks I
can't even really find out where PL_sv_undef is defined and how it is
defined. I made a very simple test case with dso that are dlopen and share
variables which I thought was similar to the PL_sv_undef scenario, but they all
work fine.
|
- Re: Perl5, Linux and Dynamic Loading Problems Christopher Mihaly
- Re: Perl5, Linux and Dynamic Loading Problems Anton Berezin
