On Mon, Mar 12, 2012 at 07:18:36AM -0700, roderich.schupp_at_googlemail.com wrote:
> On Mar 12, 9:51 am, Stefan Sperling <s..._at_elego.de> wrote:
> > Well,is libtool is constructing a linker command that which
> > contains -L /usr/lib64 which causes the linker to pick up svn
> > libraries that are already installed there.
>
> It's most likely not libtool itself that's to blame here.
> May bet is on some misconfigured pkg-config (*.pc) file
> (or some old-style foo-config script) that leaks "-L /usr/lib64"
> into your build.
It might be some dependency that rupert needs for this build and which
is either located in /usr/lib64 or needs a library installed there.
> > You should uninstall previously installed subversion libraries
> > before the build.
>
> Not very helpful. Probably better to set up a chroot environment
> for a clean build. The cost of setting one up would probably
> outweigh the pain of having to check for "contamination"
> after every build with just a few builds.
Yes, a chroot would help too. The main point is to somehow get the
old libs out of the way so the build process cannot see them.
> > You could also try to force a shared library version number
> > increment. Both sets of libraries have number 1 so are considered
>
> That's a totally separate issue. You can't bump the so version
> for every trial build.
Ah, you're correct that it may not be related to rupert's problem.
What I meant is actually a problem with upgrades between minor versions
(like 1.5 to 1.6) and the error is usually different (cannot find symbol
'foo'). Thanks for pointing that out.
> > But every downstream packager handles this
> > differently so there is no point in us doing this.
>
> That's one of the lamest excuses I've heard in a long time.
Is that a cheeky way of saying that you have found a way to reconcile
the entirely contradictory shared library versioning rules that exist
in Debian and OpenBSD packaging? If so, I'll buy you a pangalactic
gargle blaster.
Received on 2012-03-12 16:13:32 CET