subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Neyman <sti...@att.net>
Subject Re: Problem with subversion-perl RPMs from WanDisco?
Date Fri, 12 Sep 2014 16:57:49 GMT
On Friday, September 12, 2014 09:45:32 am Philip Martin wrote:
> Alexey Neyman <stilor@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.

Mime
View raw message