On Fri, 2006-05-05 at 21:48 +0100, Peter Tribble wrote: > > 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
It's not only tools we are talking about, but also libraries. > 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. Most of GNOME falls into this category. This is the result of a lot of work by both the C compiler and the GNOME teams. GNOME now builds just fine if you install a few GNU utilities. The required libraries are already in Solaris, in /usr. > It starts off with the initial problem that configure is often > completely incapable of making sensible decisions - or even running It can only do what it's told (; > 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). I've seen that a couple times, usually caused by sed problems. I wouldn't say that it happens often, but then again, I'm have a few GNU tools in my environment that are not part of Solaris. > 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.) Or you already have those libraries, but not in the default search paths and configure won't find them. This is one of the issues we're trying to resolve. Of course, you can set CFLAGS, CPPFLAGS, LDFLAGS, PATH, PKG_CONFIG_PATH, whatever, all you need to know is what mechanism is used by the "hiding" library to identify itself and what tests are used in configure. > How to fix that? Simply bundle more libraries, and keep the ones > we do supply up to date. Right. And keep them somewhere they can be found but avoid conflicts with existing Solaris interfaces. Laca
