RE: Subversion Build Issues - 1.10.6

Thank you Daniel, Thorsten and Nathan. After uninstalling 'libsvn1' and 'libapache2-mod-svn', I was able to build Subversion.

Regards,
Sanad MM

-----Original Message-----
From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Sent: Friday, 26 June, 2020 9:16 AM
To: Thorsten <tg_at_freigmbh.de>
Cc: Sanad Majid <sanad.majid_at_LumaCyte.com>; users_at_subversion.apache.org
Subject: Re: Subversion Build Issues - 1.10.6

WARNING: This message originated from an external sender.
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Thorsten wrote on Fri, 26 Jun 2020 10:24 +0200:
> Hello,
>
> Well I am no expert and thus i might be completly wrong, but it seems
> to me that you placed subversion in the path
>
> /root/subversion-1.10.6/
>
> and trying to install it to
>
> /usr/local/lib
>
> So it seems a little bit strange that a lib from a completly different
> path is intefering.

It's a known issue on Debian systems; I predicted it in my first reply.
See this old bug report:

https://bugs.debian.org/291641 libtool: Checks dependencies of shared libraries without honouring RPATH

> It assume that this is a an old version of svn which was already
> installed on the machine?
>
> /usr/lib/arm-linux-gnueabi/libsvn_fs_fs-1.

That was probably installed by a package, rather than by someone manually building from source.

> So a few things you can try from easy to complicated:
>

  - Look for new Subversion packages that you can install on top of the
    existing ones

> - try to compile subversion on a fresh setup
>
> - try to get rid of the existing version of svn

Either by uninstalling the "libsvn1" and "libapache2-mod-svn" packages (which you probably have installed), or by temporarily removing the *.so files installed by those packages for the duration of the build/install process. (Renaming those files, or moving them to another directory, would suffice.)

In the temporary removal case, you'll want to also do that to *.so files shipped by other Subversion-related packages. Precisely, we're talking about the set of binary packages built from the «subversion» source package, i.e., those listed by «aptitude search '~i ~e subversion'», but it might be easier for you to find the relevant packages by going through the list of installed packages that depend on libsvn1. Once you have identified the relevant packages, take them through «dpkg -L», or just uninstall them _en masse_.

By the way, given that you're switching from (probably) a Debian package's libsvn_foo.so to self-built libsvn_foo.so, see:
https://sources.debian.org/src/subversion/1.8.10-1%7Ebpo70+1/debian/patches/apr-abi/
In a nutshell, this means that if you install from upstream sources, build an app against libsvn, and then install the Debian package again, the app will fail to run.

> - fiddle with the linker so that the other svn does not get picked up
>
> Best regards,
>
> Thorsten Goetzke

Cheers,

Daniel
Received on 2020-06-26 22:23:54 CEST