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

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

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);
[download]

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com