[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with subversion-perl RPMs from WanDisco?

From: Alexey Neyman <stilor_at_att.net>
Date: Fri, 12 Sep 2014 09:57:49 -0700

On Friday, September 12, 2014 09:45:32 am Philip Martin wrote:
> Alexey Neyman <stilor_at_att.net> writes:
> > I tried to update subversion to 1.8.10 on a freshly installed CentOS 6.5
> > and noticed that an attempt to use Perl bindings has failed due to an
> > undefined symbol in the libsvn_swig_perl library:
> > svn_swig_pl_get_current_pool
> >
> > $ readelf -Ws /tmp/usr/lib64/libsvn_swig_perl-1.so.0 | grep
> > svn_swig_pl_get_
> >
> > 79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND
> >
> > svn_swig_pl_get_current_pool
>
> I see that the 1.8 WANdisco package installs some files into
> /usr/local/lib64. The file
>
> /usr/local/lib64/perl5/auto/SVN/_Core/_Core.so
>
> is the one that defines your missing symbol. Perhaps the problem is
> that the way you are invoking Perl means it does not load files from
> /usr/local?

Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
_Core.so as a dependency:

$ ldd /usr/lib64/libsvn_swig_perl-1.so
        linux-vdso.so.1 => (0x00007fffea3ff000)
        libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0
(0x00007f31ce700000)
        libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0
(0x00007f31ce3fa000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f31ce1cc000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f31cdfc8000)
        libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f31cdda4000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f31cdb6c000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f31cd944000)
        libdb-4.7.so => /usr/lib64/libdb-4.7.so (0x00007f31cd5d0000)
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007f31cd3a3000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f31cd186000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f31ccdf2000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003acd600000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f31ccbed000)
        libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007f31cc976000)

If I pre-load the library, though, it fails differently:

$ LD_PRELOAD=/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so /tmp/1.pl /repo
Can't locate object method "new_default" via package "SVN::Pool" (perhaps you
forgot to load "SVN::Pool"?) at /tmp/1.pl line 6.

[[[ 1.pl
#!/usr/bin/perl

use SVN::Repos;

die "Usage: 1.pl REPO" unless $#ARGV == 0;
my $repo = SVN::Repos::open($ARGV[0]) or die "Cannot open repo " . $ARGV[0];
exit 0;
]]]

> You might be able to set LD_DEBUG to diagnose the problem,
> something like
>
> LD_DEBUG=libs perl file.pl

Just as I said above, it does not even try to search for _Core.so:

$ LD_DEBUG=libs /tmp/1.pl /repo 2>&1 | grep _Core
$

As a side question, why does this package install stuff into both /usr/lib and
/usr/local/lib?

Regards,
Alexey.

>
> (run any executable with LD_DEBUG=help to see other options).

>
> > This symbol is defined in the library packaged into 1.9.0-alpha2 RPMs,
> > but not in any 1.8.x/1.7.x RPMs.
>
> The handling of the symbol changed in 1.9.
Received on 2014-09-12 18:58:19 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.