On Monday 21 April 2008 18:12, Michael Schuster wrote: > Lukas Oboril wrote: > > On Fri, Apr 18, 2008 at 1:16 PM, David Finberg <David.Finberg at sun.com> wrote: > >> On Fri, 18 Apr 2008, Lukas Oboril wrote: > >>>> 1) STDCXX doesn't properly deal with the compilers not being in > >>>> /opt/SUNWspro, it does some header file mucking and moving based off > >>>> of /opt/SUNWspro/prod/include and screws up for a non-default > >>>> comiler. Check the Solaris directory for the offender.
Regarding this original problem, I think we need to be pretty clear: if you're not running The Right Environment (and this needs to be documented on Techbase as well, if not better) consisting of SS12 + patches in /opt/SUNWspro and a home dir at $(HOME) with a pkgtool directory ~/packages then right now building is out of the question. It's a matter of distributing the available effort from the core team "best" in some way: chasing variables in installations or getting the core software to work or pulling in new developers. > >> There's a hard path to /opt/SUNWspro in one of the configure scripts, > >> if that could be changed to dirname $(CC) it might just work. Or maybe > >> not. Does readlink -f $(CC) produce useful results for you? This is one of those cases where patches from you (David in this context) are pretty essential: none of the regulars have their SS12 installed somewhere else so it's difficult to invent a solution. > > I'm planing something like that for next version of CBE (which will > > replace KBE). Next relase should be within one month. Has there ever been a "release" of KBE? It's been pretty stable over the past few months, with just a few things here in april -- removing superfluous parts, mostly. > Last time I went through a compile cycle of KBE on Sparc (I never manage to > continue much further before job-life kicks in, but that's a different > story ...), I had the impression that it worked - I believe the result of > that compile cycle is still available on bionicmutton ;-) Yes, those are still up there now. Last time I kicked my U45 to life it worked fine as well. Again, with exactly the default configuration. > As much as I admire and expect continuous improvement not only of KDE > itself but also of the infrastructure (ie things like KBE - and I believe > Luc has done a terrific job!), I wouldn't expect that to happen in the > "mainstream", as it were. As it is, because KBE is frequently changing > under our pants, I think people are having a hard time keeping up and > working on K*D*E - and remember, that's what we are trying to get done! While we have a pretty good build setup -- again, in default configurations -- we're not very good in packaging stuff up and making it available. That's a consequence of the composition of the team, I think. We need people who can handle compilation issues. Let's face it: once you get past KBE and KCE (which contain "known good" and patched up versions of released software) you are going to hit KDE SVN, and that is still rife with missing paths, LFS assumptions, etc. and you're going to end up equally stumped, just with a few days compile jobs more under your belt. That's no way to carry on. But .. (see further) > I'd advocate for a fairly stable (or "known good") release of KBE at a > point in time that's not too far in the future (like yesterday ;-), and any > further development in a branch/fork/sandbox, that only gets pushed back > when a) it shows so much benefit that it outweighs the inconvenience > or > b) we have a serious problem with the existing KBE that a simple patch(*) > cannot address. The thing is, KBE *is* "known good" for the people using it every day. It builds without a hitch for me whenever I try it. It obviously doesn't for some other people, so what are we to do? Divert effort into getting KBE to work under all circumstances, or go with the old-fashioned "send patches" approach and carry on with KCE or KDE? I can tar up my current KBE for amd64 and stick it on bionicmutton if that could be useful to anyone. > PS: if you get the impression that I'm repeating myself, that's probably > because I am. $ echo echo echo [ade]
