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

[Hal Murray]

address@hidden said:
> 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. 

I understand that makes things interesting.

After the RPATH/RUNPATH stuff got sorted out, I had no troubles running scons 
check with or without chrpath.

> 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.

> It's the requirement to do load-path editing in order to plug that security
> hole that really complicates things;

It's more complicated than just a security hole.  If you don't fix the R*PATH 
stuff, the installed code will try to use the development libraries.

> 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?

----------

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

>From a previous message:

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?


-- 
These are my opinions.  I hate spam.