2 Dec 2005 22:55
Re: gcc, specs, and rethinking the sidai -R thing
Will Partain <partain <at> dcs.gla.ac.uk>
2005-12-02 21:55:47 GMT
2005-12-02 21:55:47 GMT
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 placeI 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 ------------------------------------------------------- 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
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
-------------------------------------------------------
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!
RSS Feed