Re: gcc, specs, and rethinking the sidai -R thing

[Jim R. <jm...@qu...>]

Will Partain wrote:

>Jim, I agree with your misgivings.  After all, something must've
>pushed me into this -R thing in the first place :-)
>
>I wonder if some sort of hybrid scheme would make sense?  I observe
>that not all .so files are created equal...
>  
>
In some cases it will make sense - yes.

>* things like libgcc_s.so -- every program needs it; carefully managed
>  by the GCC lads... Why not just put this in your ld.config...
>
>    /our/.-ark-deploy/gcc--4.0.2/lib
>    /our/.-ark-deploy/gcc--3.4.3/lib
>    /our/.-ark-deploy/gcc--2.95.3/lib
>
>  ... and declare victory?  If your program picks up the version from
>  a different version than what you might've expected, it will almost
>  certainly be OK.
>  
>

You're probably right about the resilience to version mismatches 
aspect.  And in the context of within a managed "cluster", doing 
something like this isn't particularly hard or evil.  Reasonable choice 
if it saves some headaches.

>* things like libz.so -- very stable interfaces; likely only upgraded
>  for security reasons; ubiquitous use; versioning done responsibly.
>  Again, having these picked up from a well-controlled ld.config will
>  probably be OK.
>
>* things like the Berkeley DB libraries -- you do _not_, on pain of
>  death, want a program picking up a version other than the one you
>  explicitly intended! -- a horrible horrible death will certainly
>  follow.  -R all the way.
>  
>

I think these three "classes" are probably reasonably representative of 
all the use cases, and it is clear that there is some variation in "how 
much it matters".

>Of course, judgement calls are being made in all of that.  So (if you
>decided to try to distinguish between those cases), it would a
>delicate bit of ARK scripting to keep it all together.
>
>Meanwhile, I wildly support that you should be able to do the kinds of
>things you're trying to do ("you don't need anything but a raw box").
>  
>

This one flies right in the face of the libgcc approach above.  In order 
to get to this level of sophistication/portability, you have to solve 
whatever issues there are completely and "correctly", since you can't 
manipulate ld.config.  Somewhat unfortunate, but a fact of life.  The 
ways to solve it that I see are:

1.) -R at build time, specifying all of the libs, and paths to 
version-specific deploy dirs -- the way it is done now.

2.) A wrapper that sets LD_LIBRARY_PATH on a per-app basis, with the 
info that would have been in "-R" above.

3.) Install apps into some shared dir, abandoning the current 
version-specific deploy dirs as the $prefix.  Implies giving up full 
control of  the ability to robustly deploy multiple versions of an app 
or lib.  If that "shared dir" isn't already on ld.config's path, still 
requires some amount of solution ala 1 or 2 above, but the level of 
effort will be seriously lowered -- since there's only one path to 
push.   If that dir is /usr/local; it's likely already solved.


>(Let me know if I've forgotten something, e.g. from earlier in the
>thread.)
>  
>

I've been puzzling on this for some time, and I think that the current 
approach, while it's a pain in the !@#, is the best one. 

I've nailed down my current biggest headache; it's that my current 
version of libstdc++ that I have built doesn't have a -R path to libgcc 
built in.  Now I just have to figure out how to fix it.


Jim