[gpsd-dev] Fundamental problems with dynamic linking

[Eric S. Raymond]

Hal Murray <address@hidden>:
> Is the problem that gpsd is trying to maintain the library and a client in 
> the same package?

No.  The fundamental problem is that I insist on being able to run a
full regression test in the build directory before 'make install'.
That requirement collides with the way shared libraries work.

Even so, this wasn't a major problem before Bernd (correctly) insisted that 
we had to remove the build directory from RPATH because it was potentially
a privilege-escalation hole.  That's when I had to being in chrpath. 

That portion of the build has been a continuous problem since -
nothing I've done to it satisfied everyone, and a couple occasions
people have forgotten history completely enough to pester me to
"fix" things in ways we previously tried that failed (yeah, I'm
looking at you, Greg Troxel, but you weren't the only one).

None of this would be a serious problem if the dynamic-linking facilities
weren't a poorly-documented swamp.  Hal, I think you exposed the biggest
land-mine when you figured out the precedence difference between RPATH
and RUNPATH - the point is that I stared at those docs for a long 
time and didn't see the precedence issue, and our use case is just
unusual enough that I couldn't find worked examples.

Bernd thinks the problem is SCons.  He's wrong; the hoops I had to
jump through to install shlibs properly were annoying, but that part of
it has been a solved problem for a long time now.  It's the
requirement to do load-path editing in order to plug that security
hole that really complicates things; the equivalent hair would
be as bad or worse in any other build system I know of.

In retrospect, I tried to make the build too clever.  It did make some
sense to use shared libraries as much as possible when our dominant
user case was laptops - the memory-footprint gains were quite small
but they were real.  Now that most of our deployments are embedded
sharing gains nothing in the typical case.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>