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

[Will P. <pa...@dc...>]

Responding to Jim Rowan... sorry to be so slow.

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

[Recap: "my" [vague] proposal was: lose the -R stuff, have some extra
ARK gunk to "manage" the ld.config game (where to find .so files).]

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

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

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

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

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

Will