Re: [gpsd-dev] Fundamental problems with dynamic linking

[Eric S. Raymond]

Hal Murray <address@hidden>:
> > 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). 
> 
> Please document the things that didn't work so somebody else can avoid them.

Tall order. It would require me to grovel through a lot of archived mail. 
I might have time to do that in the future, but today is not that day.
 
> > Now that most of our deployments are embedded sharing gains nothing in the
> > typical case. 
> 
> I don't understand.  I'm assuming that "embedded" means cell phones.  What's 
> the typical use case?  If some app (or whatever) is using gpsd, won't there 
> will be 2 copies of libgps in memory?  Isn't memory tight on cell phones?

Yeah, but I'm pretty sure those deployments are using Java for the
client side.  Last I checked Java runtimes couldn't use stock C
shlibs, and if they can't we end up with two copies resident anyway.
This might have changed while I wasn't looking.

On a design level, the original purpose of libgps was to seal clients off
from the wire protocol and save them the complexity overhead of having to
parse it.  Using JSON changed the tradeoffs there. For almost all languages
other than C, unpack-JSON-to-native-structures is a standard-library thing. 

> I've forgotten.  What was the straw that broke the camel's back this time?

Bernd doesn't like my proposal to static-link our binaries.  I think he is
now so fixated on finding problems with any SCons-based recipe that he cannot
rationally evaluate less intrusive fixes.  We may lose him over this, but 
the way he wants to "fix" things (moving to a two-stage build system) is in
my opinion a complete non-starter.

> How many options are there?
>   Link using local libraries.  Test.  Use chrpath to fixup the installed copy
>   Link using local libraries.  Test.  Re-link to install.
>   Link using installed library locations.  Use LD_LIBRARY_PATH to test
>     (On Linux, that requires linking with RUNPATH rather than RPATH)
>   Install, then test using installed libraries.  (Needs (semi-)dedicated 
> machine.)
>   Don't use shared libraries.
> 
> Are there any others?

Not that I can think of. At the moment I'm pursuing "Don't use shared
libraries." because it seems the simplest path.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>