Search::Xapian Perl module should specify RTLD_GLOBAL in dlopen call

[David F. Skoll]

If you're using Search::Xapian as well as other C++ code that links against libxapian.so, C++ exceptions mysteriously fail because the weak symbols in each .so don't match, so the C++ runtime cannot identify the types of the exceptions.

A simple one-line patch to Xapian.pm fixes the problem:

diff --git a/Xapian.pm b/Xapian.pm
index 643edc1..d071721 100644
--- a/Xapian.pm
+++ b/Xapian.pm
@@ -38,6 +38,11 @@ require DynaLoader;
 
 our @ISA = qw(DynaLoader);
 
+# We need to use the RTLD_GLOBAL flag to dlopen() so that other C++
+# modules that link against libxapian.so get the *same* value for all the
+# weak symbols (eg, the exception classes)
+sub dl_load_flags { 0x01 }
+
 # This allows declaration      use Search::Xapian ':all';
 # If you do not need this, moving things directly into @EXPORT or @EXPORT_OK
 # will save memory.

[David F. Skoll]

Simple patch to Xapian.pm to pass RTLD_GLOBAL to dlopen() in DynaLoader

[Olly Betts]

Thanks for the patch.

It would be good to make sure this fix works on all platforms, and that it continues to work. How feasible is it to write a regression test?

I guess we'd need a second Perl module which links to xapian-core and to throw an exception and see if we can catch it, or something like that?

[David F. Skoll]

Hi,

Give me a couple of days... I'll try to work up a test case.

Regards,

David.

[David F. Skoll]

Test case illustrating dlopen problem.

[David F. Skoll]

Hi,

My colleague Dave O'Neill came up with the test case in the attachment xapian-dlopen-fix-with-test-case.patch

Unfortunately, running the test is a bit ugly. You have to do this:

# Build Xapian
perl Makefile.PL && make

# Run our test specifically
cd t/ticket-522 && make && make test

The "make test" in t/ticket-522 fails on Debian GNU Linux 5.0 (Lenny) if the sub dl_load_flags { 0x01 } line is commented out, but succeeds if it is present.

Regards,

David.

[Olly Betts]

Great, thanks - I've hacked the testcase around and managed to get it to run fairly sanely as part of "make test" from the main project, and committed this to trunk in r15215.

The fix itself is simple and seems safe, so we should certainly backport the fix to 1.0.x (not so sure about the testcase!), so setting the milestone appropriately.

[Olly Betts]

OK, backported to 1.0 in r15217. The test worked with just needing to change the exception name (1.0 throws DatabaseCreateError instead of DatabaseOpeningError here) so I backported that too.