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

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

This one slipped under my radar somehow -- just noticed it.

Will Partain wrote:

>Following on from some of Jim Rowan's recent experience (and mine),
>I'm rethinking some of the Sidai way of dealing with shared
>libraries...
>
>...
>  
>

> <>Now, there's another mechanism for this kind of thing, namely setting
> up ld.config (or equivalent). You tell the runtime linker "here are
> some places to look for shared libraries", and then it does the rest.
> So, for example, I did [on a Sun]...
>
> sudo crle -l /usr/lib:/our/.-ark-deploy/gcc--4.0.2/lib
> ... and my libgcc_s problems went away forever :-)
>
> Now, it's quite easy to play this ld.config game so that it's just as
> ill-disciplined as the "throw it all in /usr/local/include" game. But
> surely there is a way to gain most of the discipline of the "I'll tell
> you _exactly_ what I want" -R'ing scheme. Something like... each
> package providing libraries has a field...
>
> <ld-config-spec>
> <param name="prefix">!sidai_prefix</param>
> <string>$prefix/lib</string>
> </ld-config-spec>
>
> ... and some small program comes through and collects these, and sets
> ld.config appropriately.
>
> I haven't done all this yet, but am seriously considering it. Love to
> see all that -R stuff go up in smoke. Thoughts?


I'd love to see the -R stuff go away as well.  It is a major detractor.

However, your proposal causes the behavior of ark installed programs to 
be dependant on the configuration of the machine (OS) itself -- 
something that I don't believe was previously a requirement (beyond 
having the right stuff mounted/accessible).  This has at least two side 
effects:

1.) It means that these apps have no chance of running on a machine that 
isn't specially configured (unless they're run by a user that has 
LD_LIBRARY_PATH set appropriately).  I'm toying with the possibility of 
building "islands" of ark-ness in AFS, so that people at other places 
can see how cool it is with respect to building/managing apps.      I'd 
really like to build a set of apps that can be run from any box that has 
the appropriate OS, and by a user that does nothing more than adjust 
their PATH.

2.) It seems to preclude more than one run-time environment per 
machine.  A user that wants to run version abcde.alpha of something 
won't be able to (reliably) because the loader finds the wrong shared 
library. 

I don't think this sounds like our ideal solution.  :(

Jim