Re: Dynaloader/XS: sharing C symbols across shared objects

[syphilis]

Basically, if the Hello.pm shared object exports the say_hello() function, then all works fine. Otherwise you get the failure you reported.

There's an (documented) EU::MM parameter called FUNCLIST that's helpful here, but it hasn't been made available to Inline::C - so I think that, wrt Inline::C, you're snookered. (Though, having said that, someone may well come up with a different solution.)

However, if you convert Hello.pm to a normal XS module, and provide WriteMakefile() in its Makefile.PL with:

    FUNCLIST => ['boot_Hello','say_hello'],

then all should work fine. At least it does for me, on Win32.

However, as I understand it, you don't control the real world equivalent of "Hello.pm". Does that, in itself, pose a problem ?

Cheers,
Rob
Update: Inserted boot_Hello into the FUNCLIST arg. (It's also needed, I believe.)
Update 2:The Inline::C script also then needs to link to the Hello shared object or it's import lib. (Things aren't being quite as simple as I recall ... it's looking more and more kludgy by the minute :-)

[creamygoodness]

Basically, if the Hello.pm shared object exports the say_hello() function, then all works fine. Otherwise you get the failure you reported.

That makes sense to me. If I understand correctly, then the failure mode is very similar to what you get when trying to load a function that a Perl module doesn't export.

The solution would seem to be to recompile Lingua::Stem::Snowball with additional options that specify that its shared object should export the necessary symbols. Fortunately, I maintain Lingua::Stem::Snowball, so I can release a new version if need be.

I've been trying with the gcc -export-dynamic, which I specify using Module::Build's extra_linker_flags option (and verify that it appears on the command line). No luck yet though. Hmm.