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

[syphilis]

+sub dl_load_flags { 0x01 }

Wow !! I didn't realize that things were *that* simple on nix type operating systems. (I've just checked on my old mandrake-9.1 box, and things really *are* that simple.) There's certainly more than that required on Windows - though I realise that's probably something that's not an issue for the OP.

For a start, on Win32 we need to have the dll export the symbols - hence the usefulness of 'FUNCLIST'. (I was forgetting that probably wouldn't be an issue on most other operating systems.)

Secondly, on windows, there's a need to be able to resolve all symbols at compile-time. But, on my linux box, I've just realised there's no such condition to be met. As an example, the following Inline::C script runs fine on linux, but fails to build on windows:

use warnings;

use Inline C => <<'EOC';

void extern crap();

void foo() {
     crap();
}

EOC

print "Compiled fine";

On linux (with gcc) that outputs simply Compiled fine, but on windows (using the MinGW port of gcc) the build phase fails with:

try_pl_d349.o:try_pl_d349.c:(.text+0x5): undefined reference to `crap'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\try_pl_d349\try_p
+l_d349.dll

This is, no doubt, old news to many here ... but the starkness of the differences took me somewhat by surprise.

Cheers,
Rob

[creamygoodness]

Windows is a target for both KinoSearch and Lingua::Stem::Snowball, but it's such a pain to deal with that compatibility lags in the dev branch of KS. For today, I just needed a band aid to get a user who's working with the KS svn trunk on Linux up and running; the DynaLoader patch does that. For a more robust solution, I'll need to take salva's suggestion.

But here's a question for you: is it really "dynamic linking" if you need to resolve every symbol at compile time? I mean, the whole point of dynamic loading is to put off that resolution: "I'll tell you where the actual compiled code to run crap() is the first time you need it at runtime."

[syphilis]

For a more robust solution, I'll need to take salva's suggestion

Yes, salva's solution (a salvation ?) seems like a good one - though I haven't yet been able to work out exactly how to implement it. Pointers to functions in C ? ... then wrapped in an SV ? ... that's more than enough to frighten me.
If someone feels inclined to present a simple demo of the procedure, I, for one, will certainly be taking a good look at it.

At RFC: Setting up a minGW compiling envronment for Perl 5.10 there's a long and drawn out discussion that unravels this very same issue wrt Glib and Cairo on Win32. Seems that Glib and Cairo might be much more Windows-friendly if the approach presented by salva were adopted by their developers.

is it really "dynamic linking" if you need to resolve every symbol at compile time?

The same question is asked at http://sig9.com/node/35 - and a simple demo solution that involves the LoadLibrary() and GetProcAddress() functions (from the Windows API) is provided. I imagine it would be very tiresome to attempt to incorporate that approach into portable XS code. (I note that the "solution" presented there also involves "pointers to functions".)

Cheers,
Rob

[creamygoodness]

Pointers to functions in C ? ... then wrapped in an SV ?

C function pointers are directly analogous to perl subroutine references. The big differences are...

• They're typed, so function signatures must match.
• The syntax for declaring them is bloody awful. In fact, it's so awful that many people use typedefs whenever possible.
• You can't verify that a non-NULL function pointer actually points to anything valid, unlike in Perl where you can verify a sub ref with ref($sub).
Here's a demo for passing a function pointer around via SV.

use strict;
use warnings;
use Inline C => <<'END_C';

typedef void
(*hello_func_t)();

void
hola_mundo()
{
    printf("Hola, mundo!\n");
}

SV*
get_hola_mundo_func_ptr()
{
    return newSViv( PTR2IV(hola_mundo) );
}

void
do_hello(SV *sv_with_func_ptr)
{
    IV temp = SvIV(sv_with_func_ptr);
    hello_func_t hello = INT2PTR(hello_func_t, temp);
    hello();
}


END_C

my $func_ptr = get_hola_mundo_func_ptr();
do_hello($func_ptr);