Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

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

by syphilis (Bishop)
on Jun 10, 2008 at 07:06 UTC ( #691166=note: print w/replies, xml ) Need Help??

in reply to Dynaloader/XS: sharing C symbols across shared objects

+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.


Replies are listed 'Best First'.
Re^2: Dynaloader/XS: sharing C symbols across shared objects
by creamygoodness (Curate) on Jun 10, 2008 at 19:11 UTC

    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."

    Marvin Humphrey
    Rectangular Research ―
      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 - 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".)

        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);
        Marvin Humphrey
        Rectangular Research ―

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://691166]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2021-01-25 08:03 GMT
Find Nodes?
    Voting Booth?