On Mon, Mar 12, 2012 at 10:20:55PM +0100, Roderich Schupp wrote:
> On Mon, Mar 12, 2012 at 16:12, Stefan Sperling <stsp_at_elego.de> wrote:
> > 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.
>
> Probably. But that is no reason to inject -L/usr/lib64 into the linker
> flags - pkg-config files should _never_ add flags referring
> to locations that are in the standard search paths, e.g.
> /usr/lib{64} for libraries of /usr/include for header files.
> But there are a lot of sloppily written pkg-config files out there...
http://wiki.debian.org/RpathIssue has some interesting notes about
incompatibilities between Redhat and Debian in this regard. It's
unlikely that Rupert is running into these since he is compiling
on Solaris. Still, conflicting conventions between systems don't
make these kinds of problems any easier to deal with :(
Luckily the problems described in the above link seem to have been
resolved in upstream libtool by now.
> > 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.
>
> I guess the correct answer should have been:
> Subversion uses its own scheme of "versioned symbols"
> (by never changing the signature of a function foo(),
> instead adding foo1(), foo2() etc) and also being
> careful when adding to structures.
Yes, that is why Subversion is a bit of an odd case. You can always link
binaries using old 1.x APIs to newer 1.y libraries. We never rename
existing released symbols.
> > the entirely contradictory shared library versioning rules that exist
> > in Debian and OpenBSD packaging?
>
> Why single out Debian here? I can't see a difference wrt versioning
> rules in all major Linux distributions.
Debian deliberately only links direct dependencies but not indirect ones.
This allows library updates without recompiling all indirect dependencies
but can result in more than one library linked into the same executable
at runtime and it can also break builds:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641
I don't know if there are other Linux systems that use this approach.
Anyway, this thread has wandered off-topic a bit.
I wonder if this conversation is helping Rupert or if it just leaves
him scratching his forehead :)
Received on 2012-03-12 23:12:48 CET