On Mon, Mar 12, 2012 at 07:18:36AM -0700, roderich.sch...@googlemail.com wrote: > On Mar 12, 9:51 am, Stefan Sperling <s...@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.
