On Fri, 2006-05-05 at 10:42, John Rice wrote: > John, > > When you say: > > "I'm a bit concerned that "blessed as a GNU project" is an odd match > to the desired features of /usr/gnu/." > > I know what you mean. My goal in the orginal post was to have all the > various OSS tools present on Solaris in a way that makes it very easy > to build OSS software out of the box.
One fundamental problem I have with this whole discussion is that I don't see tools as the fundamental issue. As an end user, then you need: gtar, gmake, ginstall, gm4, gcc, and gsed wouldn't hurt. These are mostly in /usr/sfw already. End users don't need auto* and the like. I've had the entire gnu set of tools (and more) installed for years, and it doesn't really help - most software simply doesn't build out of the box any more, and I don't recall many cases (if any) where tool availability was the fundamental problem. It starts off with the initial problem that configure is often completely incapable of making sensible decisions - or even running to completion without failing itself. (As opposed to exiting because it found something that needed to be fixed.) I'm unsure whether this is a fundamntal flaw in the design, or whether it's always being misused (or both). If you're lucky, you'll find that configure tells you plainly and cleanly that it can't find some library (as a rule) that it needs. Generally, assuming configure actually works, the problems boil down to missing libraries or APIs. So off you go and suffer the pain of getting all the dependent libraries built. (Or updated.) How to fix that? Simply bundle more libraries, and keep the ones we do supply up to date. Then there are missing APIs. Sometimes the author is just careless and uses a non-portable version of a portable api, and that isn't too hard to fix. Sometimes, it would be easier to bite the bullet and simply add the API. As an example, I filed 6421095 requesting that strcasestr() be provided. Then you have to fight libtool; if that fails there's no effective way that I've yet found of fighting back. This assumes that the code actually compiles. Sometimes, it just doesn't. In years of doing this, tools haven't been a problem. My experience is also that software isn't necessarily any easier to compile under Linux. If it is, it's because the libraries and code are similar, and dependencies are more likely to be met out of the box. But other than that it wasn't any easier - sometimes harder, because I usually only had the single (OS provided) working environment and was stuck with it, whereas under Solaris I could switch between several different environments to try and get better results. I suspect that binary distribution is sufficently advanced that ab-intio building of software by end users is getting relatively rare under Linux. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
