Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have been trying to wrap my head around this one for a while but to no avail. I am working on the embedded Perl interpreter for Gaim and currently it does not work with the most current development branch.

Everytime the PerlInterpreter would run it would crash Gaim with the error '...unresolved symbol: PL_sv_undef....' from inside DynaLoader. I traced this back to a change in the way plugins are loaded where g_module_open now enforces local binding of symbols. This problem was corrected by linking Gaim.so (my library of XSUBs) to libperl.a. No more unresolved symbols. However, now the interpreter would segfault when loading the library Gaim.so.

I ran gaim through a debugger and found it was seg faulting when DynaLoader called boot_Gaim and tried to setup the Perl stack. It dies somewhere in the dXSARGS macro. I have tried a bunch of different ways of building my libraries and code, but it still crashes Gaim at this point when local binding is enforced. I tried to load other Perl modules that utilize DynaLoader and they crash in a similar fashion. As soon as local G_MODULE_BIND_LOCAL is not set for g_module_open, the problem goes away, but has the bad side effects of putting every plugin's symbols in the global name space.

Thank you for any advice.
  • Comment on Embedded Perl Interpreter Crash at boot_MY_MODULE

Replies are listed 'Best First'.
Re: Embedded Perl Interpreter Crash at boot_MY_MODULE
by anonymized user 468275 (Curate) on Jul 05, 2005 at 15:39 UTC
    You say Gaim.so is your library of XSUBs and you are linking it to libperl.a. I don't have my own machine here to check this out, but my first reaction is, is it not possible that you are fooling Gaim into using your .so instead of the one it normally depends on? If so, calling it something like gaimperlint.so might do the trick.

    One world, one people