lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <wellnho...@aevum.de>
Subject Re: [lucy-dev] Sample extension for Lucy
Date Fri, 27 Apr 2012 12:22:03 GMT
On 27/04/2012 00:40, Marvin Humphrey wrote:
> The Clownfish header language currently supports such a feature in its parcel
> declarations:
>
>      parcel KinoSearch cnick Kino;

OK, I wasn't aware of that feature.

>> In WhitespaceTokenizer.cfh I had to add a __C__ block that includes
>> Lucy/Analysis/Inversion.h because the generated XS needs the LUCY_INVERSION
>> VTable. That's not ideal.
>
> Agreed.  IMO what it should look like instead is either something like this...
>
>      parcel WhitespaceTokenizer;
>      use Lucy::Analysis::Tokenizer from org::apache::lucy::Lucy v0.4;
>
> ... or like this:
>
>      parcel WhitespaceTokenizer;
>      use org::apache::lucy::Lucy v0.4;

The latter option of "using" whole parcels should be enough for a start.

>> There's an intricate problem with XSLoader that only manifests when running
>> the tests. See the comment in WhitespaceTokenizer.pm.
>
> Sheesh, how goofy.  I hope we find a fix for that eventually, so that
> nobody else has to go down the lengthy debugging path you must have gone down.

The source of the problem is that XSLoader tries to find the library 
file by working backwards from the filename of the Perl module. For 
example, when testing Lucy, the Perl module is in blib/lib/Lucy.pm. 
XSLoader ends up looking for the library in blib/lib/auto/Lucy/Lucy.so 
(on Linux) which should be blib/arch/auto/Lucy/Lucy.so.

The only solution I see is to stage Lucy.pm in blib/arch instead of 
blib/lib. But that's something Module::Build does for us at the moment.

> Here are the two tweaks I had to make to build and pass tests on OS X:
>
>    * Hack in a Clownfish include directory manually for when Clownfish::CFC and
>      Lucy are not installed into $Config{installsitearch}.
>    * Comment out the "extra_linker_flags" argument in Build.PL.
>
> On OS X, you get this error with you try to link against Lucy.bundle:
>
> ld: in /Users/marvin/Desktop/scratchlib/lib/perl5/darwin-2level/auto/Lucy/Lucy.bundle,
> can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB)
> collect2: ld returned 1 exit status
>
> Here's the explanation:
>
>      http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
>      One Mach-O feature that hits many people by surprise is the distinction
>      between shared libraries and dynamically loadable modules. On ELF systems
>      both are the same; any piece of shared code can be used as a library and
>      for dynamic loading.

So we should use $Config{so} instead of $Config{dlext}.

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

Nick

Mime
View raw message