Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Alien-SVN CPAN distribution.

Report information
The Basics
Id: 73109
Status: open
Priority: 0/
Queue: Alien-SVN

People
Owner: Nobody in particular
Requestors: jettero [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: v1.6.12.1
Fixed in: (no value)



Subject: libtool linking in /root/.cpan -- annoying having to run as root to load /root/.cpan/.../.libs
I'm having a problem with the subversion build process. I have no idea what to pass to configure, but it's clear I need some other argument. I expect this is all due to my irrationally new everything under Archlinux. libtool 2.4.2-2 Maybe it's something else. I'm not really sure what to check. Basically, I get this: perl -MSVN::Core -e 0 Can't load '/usr/local/jperl/5.12.3/arch/auto/SVN/_Core/_Core.so' for module SVN::_Core: libsvn_client-1.so.0: cannot open shared object file: No such file or directory at /usr/local/jperl/5.12.3/arch/DynaLoader.pm line 200. at /usr/local/jperl/5.12.3/arch/SVN/Base.pm line 59 BEGIN failed--compilation aborted at /usr/local/jperl/5.12.3/arch/SVN/Core.pm line 5. Compilation failed in require. BEGIN failed--compilation aborted. It took me a while to figure out that this works fine: sudo perl -MSVN::Core -e 0 I finally ran strace to find the real problem... stat("/usr/local/jperl/5.12.3/arch/auto/SVN/_Core", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/usr/local/jperl/5.12.3/arch/auto/SVN/_Core/_Core.so", {st_mode=S_IFREG|0644, st_size=2070777, ...}) = 0 stat("/usr/local/jperl/5.12.3/arch/auto/SVN/_Core/_Core.bs", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 open("/usr/local/jperl/5.12.3/arch/auto/SVN/_Core/_Core.so", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\260\1\0\0\0\0\0"..., 832) = 832 fstat(5, {st_mode=S_IFREG|0644, st_size=2070777, ...}) = 0 mmap(NULL, 2778728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f857ccce000 mprotect(0x7f857cd6d000, 2097152, PROT_NONE) = 0 mmap(0x7f857cf6d000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x9f000) = 0x7f857cf6d000 close(5) = 0 open("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/tls/x86_64/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No su stat("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/tls/x86_64", 0x7fffac5e14c0) = -1 ENOENT (No such file or dire open("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/tls/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No such file stat("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/tls", 0x7fffac5e14c0) = -1 ENOENT (No such file or directory) open("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/x86_64/libsvn_client-1.so.0", O_RDONLY) = -1 ENOENT (No such f stat("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/x86_64", 0x7fffac5e14c0) = -1 ENOENT (No such file or director open("/root/.cpan/build/Alien-SVN-v1.6.12.1-gM_lzt/src/subversion/subversion/libsvn_client/.libs/libsvn_client-1.so.0", O_RDONLY) = 5 Those .libs/ files should be temporary build files. I've seen this before, and I've fixed it before, but at the moment, I can't figure it out. Any idea what to add to the build process so it links those in properly instead of linking against those temporary files during install? -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
Subject: Re: [rt.cpan.org #73109] libtool linking in /root/.cpan -- annoying having to run as root to load /root/.cpan/.../.libs
Date: Thu, 08 Dec 2011 10:25:20 -0800
To: bug-Alien-SVN [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2011.12.8 8:23 AM, Paul Miller via RT wrote: Show quoted text
> Those .libs/ files should be temporary build files. I've seen this > before, and I've fixed it before, but at the moment, I can't figure it out. > > Any idea what to add to the build process so it links those in properly > instead of linking against those temporary files during install?
No, sorry. We've struggled with this and similar problems as well. It will not reliably link to the shared lib we're installing. Sometimes it will link to an already installed system library. You can see in inc/My/SVN/Builder.pm what we're doing to install. Any insight would be much appreciated.
On Thu Dec 08 13:25:31 2011, schwern@pobox.com wrote: Show quoted text
> On 2011.12.8 8:23 AM, Paul Miller via RT wrote:
> > Those .libs/ files should be temporary build files. I've seen this > > before, and I've fixed it before, but at the moment, I can't figure
> it out.
Figured it out again. I don't know where you would want to put this in the inc/ build hierarchy, but this will get you linked correctly: sed -i -e s,_libdir\)/libsvn,_libdir\)/,g src/subversion/build-outputs.mk -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
On Thu Dec 08 21:38:26 2011, JETTERO wrote: Show quoted text
> sed -i -e s,_libdir\)/libsvn,_libdir\)/,g src/subversion/build-outputs.mk
I really thought that worked. It was something else I did because this doesn't work anymore. Also, it was missing a .*. sed -i -e s,_libdir\)/libsvn.*,_libdir\)/,g Basically, it appeared to be a situation where specifying the .la made it install the .so differently. Now I need to retrace my steps, because it was something I did before that. :p Oh well, tomorrow. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
Subject: Re: [rt.cpan.org #73109] libtool linking in /root/.cpan -- annoying having to run as root to load /root/.cpan/.../.libs
Date: Thu, 08 Dec 2011 19:27:58 -0800
To: bug-Alien-SVN [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2011.12.8 6:38 PM, Paul Miller via RT wrote: Show quoted text
> Figured it out again. I don't know where you would want to put this in > the inc/ build hierarchy, but this will get you linked correctly: > > sed -i -e s,_libdir\)/libsvn,_libdir\)/,g src/subversion/build-outputs.mk
That might point at the problem, but hacking build files doesn't sit well with me. I wonder if there's a configure switch or something us or SVN is doing wrong.
On Thu Dec 08 22:28:07 2011, schwern@pobox.com wrote: Show quoted text
> That might point at the problem, but hacking build files doesn't sit > well with me.
Excellent point. Show quoted text
> I wonder if there's a configure switch or something us or SVN is doing > wrong.
Clearly. If their ./configure and make isn't installing libraries that are linked correctly, then there's a problem with their distribution. That it hasn't been solved before makes me wonder if it's a new-ish thing in libtool. I went through this with libpbc really briefly, which is why I recall figuring it out before. There, it turned out I just had to run his installer (rather than using /usr/bin/install), although I also figured out the required linking magic. I didn't take notes though. I've actually just been going back and forth between the libpbc sources and the subversion sources in A::S and trying to mimic things from libpbc. I'm not sure the approach is valid though, because I don't think libpbc links against itself like that. On the other hand, I'm quite sure I got the libs to install into /tmp/ correctly a couple times. So I did something that worked. I was so sure it was the mode=install target thing, but that's not working for me anymore, so it was something "that doesn't matter" that I did before that. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
This patch is ultimately what I used. It's working for me, but it sucks, and you're not going to like it any more than my other (not working) ideas. I was trying to think of things you could use, ... but it appears to be beyond my skill level. This idea does work, but it won't appear to unless you distclean and rebuild bindings/swig/perl/native after you install-lib the libsvn_*.so suite. I also had to do a for i in Makefile.[a-z]*; do make -f $i; done to get things like SVN::_Ra. This is the most confusing build I've looked into ... but my git-svn works again. I'm glad this ticket is here, if only so I can remember how to get this going again some day when I forget how I did it. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
Subject: this_works_great.patch
--- src/subversion/subversion/bindings/swig/perl/native/Makefile.PL.in 2011-02-22 19:45:47.000000000 -0500 +++ /tmp/Makefile.PL.in 2011-12-09 13:05:24.056673537 -0500 @@ -16,15 +16,7 @@ my $swig_builddir = "${svnlib_builddir}/bindings/swig"; my @modules = qw/client delta fs ra repos wc/; -my @ldpaths = ("$swig_builddir/perl/libsvn_swig_perl/.libs", - map {"$svnlib_builddir/libsvn_$_/.libs"} (@modules, qw/diff subr - ra_local - ra_svn - ra_neon - ra_serf - fs_base - fs_util - fs_fs/)); +my @ldpaths = ('@libdir@'); my @ldmodules = map {"-lsvn_$_-1"} (@modules, qw/diff subr/); my $apr_shlib_path_var = '@SVN_APR_SHLIB_PATH_VAR@';
On Fri Dec 09 22:01:05 2011, JETTERO wrote: Show quoted text
> This idea does work, but it won't appear to unless you distclean and > rebuild bindings/swig/perl/native after you install-lib the libsvn_*.so > suite.
We can reorder the SVN build process, but I'd rather not build code during the Alien-SVN "./Build install" process. Is there some way this could be done *without* first installing the libraries? Show quoted text
> This is the most confusing build I've looked into ... but my git-svn > works again. I'm glad this ticket is here, if only so I can remember > how to get this going again some day when I forget how I did it.
Yeah, I'll bet good money if it were to be done today it would be a fair sight simpler. That said, if you want to take a crack at that they probably wouldn't mind, but you'll have to talk with the SVN folks directly about that. We just bundle.
RT-Send-CC: schwern [...] pobox.com
My own workaround is to not use Alien::SVN at all. It is better to use the same source for your "svn" command-line tool and libraries as for the Perl binding. And the Perl bindings to SVN is bundled in the SVN source. So the right thing to do is to use the Perl binding provided as system packages if you use the svn from system packages. So on Debian/Ubuntu I'm just installing the libsvn-perl package to have SVN::Core. -- Olivier Mengué - http://perlresume.org/DOLMEN
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.