lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Sample extension for Lucy
Date Fri, 27 Apr 2012 16:06:57 GMT
On Fri, Apr 27, 2012 at 5:36 AM, Nick Wellnhofer <wellnhofer@aevum.de> wrote:
> On 27/04/2012 14:22, Nick Wellnhofer wrote:
>>>
>>> This leads me to question whether extensions should be linking against the
>>> shared objects of their dependencies on *any* platform. Does that create a
>>> tight binding that will e.g. break WhitespaceTokenizer when Lucy gets
>>> updated?  I'm pretty sure we want runtime relocation of upstream symbols.
>>
>> On Linux I had to link against Lucy.so. Otherwise I get "undefined
>> symbol" errors when running the tests.
>
> There seem to be two workarounds on Linux: Link the main executable with
> -rdynamic or pass the RTLD_GLOBAL flag to dl_open. Since our main executable
> is perl, the former won't work. But the latter can be achieved by using
> DynaLoader with dl_load_flags set to 1.

Ah, it's *that* problem.

    http://www.perlmonks.org/?node_id=691130

    Dynaloader/XS: sharing C symbols across shared objects

    I have two XS modules, and I would like C symbols loaded by one to be
    accessible from the other.  The ultimate goal is to avoid including the
    Snowball stemming library in the KinoSearch distribution, with all of its
    compilation overhead, but instead load Lingua::Stem::Snowball and its
    associated shared object and have the Snowball C API be accessible from
    within the KinoSearch shared object.

    This works fine on Mac OS X, but not on FreeBSD or Linux.

The solution that came out of that discussion -- pass function pointer
addresses around via Perl scalars because that's guaranteed to work
everywhere -- isn't feasible here.  Nevertheless, I'd hazard a guess from the
discussion of the dl_load_flags approach in that thread that if we go that
route we're all set for all common Unixy systems.

Our next move, then, is to see whether we can make the extension work on
ActivePerl/MSVC, Strawberry Perl, and Cygwin.

Marvin Humphrey

Mime
View raw message