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

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



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click