Show quoted text> It would use the Alien::SVN installed libraries, but it was
> easily confused by other installed ones.
Our belief is that it would load the newly compiled shared
libraries during building and testing, and then it would continue
to load those same files once installed -- but from the build
directory, not the installation directory.
Once the build directory gets zapped, the load mechanism follows
the rest of the LD search path (which was set at compile time).
This search path does not include the location underneath the
Perl arch dirs where the compiled .so files were installed, so we
don't believe those copies were ever accessed once installed (at
least not on our system). Instead, if you have copies of those
shared objects in a standard installation location like /usr/lib,
it finds those. If it can't find them anywhere (for instance
because you moved libsvn_client.1.0.so out of the way for testing
purposes), it gives up.
In our case, the version in /usr/lib was not compatible with the
version distributed with SVN, and caused a segfault on load. The
first symptom was that root was able to use SVN::Client properly,
but any other user would get a segfault. That's because root was
the one that built Alien::SVN and was still able to see the build
directory and load shared objects from there, but other users
didn't have permission to access that directory and would get the
incompatible version in /usr/lib and blow up.
Note that all this happens outside the Perl XS load mechanism.
When you use the Perl module SVN::Client, it tries to load the
SWIG XS shared object for SVN::_Core, _Core.so. It finds that
successfully, but then the dl_load_file() call dispatches to the
C dynamic loader to get libsvn_client-1.0.so -- and that loader
knows nothing about Perl's @INC.
The solution was to prepend the non-standard installation
directory to the LD search path which gets baked into _Core.so at
build time.
Show quoted text> This patch looks like it may have fixed that long standing
> problem!
Excellent. :)
Show quoted text> > From what I can tell, the Subversion SWIG bindings do not
> > know how to find a .so file in a non-standard location.
>
> Yeah, I'd always assumed they did.
I would have assumed the same thing. It seems like a
non-standard install location would be a common usage pattern.
It took me a while to figure out that there were no provisions
made for that in that Makefile.PL.in!
