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.
 

Reply via email to