[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

picking up speed

Hi people,

Peter Schulte-Stracke wrote with this info ...

it's already too late (midnight) here, so the following is almost random:

(1)	 Oh I know well that it is rather late to mention that, but the 
	architecture should better be called s390g2, if you ever wish to 
	accomodate plain /390 into the distribution, because it is easier
	to work with positive flags and meanings.
	(Just compare s390, s390g2, cc -mg2 with s390standard, s390, cc -mpre-g2)

(2)	I see that dpkg-architecture does not accept the architecture string
	returned by gcc; this made a lot of problems, earlier this year, when 
	I tried to build glibc. I then found that I am not the one who repairs it.

(3)	I found that clisp fails somewhere in the libtool configure script; 
	in any case it is in need of a bit (or perhaps more than a bit) of 
	assembler coding and adapting. I would rather think that this applies 
	to most interpreters and similar programs. 
	That the hugs Haskell interpreter compiled is quite remarkable;  
	if it works, the team in Goeteborg (?) can congratulate itself. 
	I looked at clisp when I compiled it  in January or so, and I will 
	try to make it compile for the s390.

Now the entropy has taken hold of me ...


Peter,	they gonna shoot me if I say I need debian-i370 debian-s390 debian-s390g2
and whatever else comes up as the strategic architecture-du-Jour.
Debian has these Earth-tremours every so often, when somebody discovers
that i386 comes in several flavours; i[3,4,5,6]86 with/without MMX, and
he's not getting his full Bogomips worth of $CFLAGS.
I'd be inclined to want to wait until I see how the gcc-s390-toolchain gets
integrated into the mainstream gcc-toolchain and then build on that.
(Maybe we'd call it the v390; it's virtually all there except for the ..uhhh..
AHI-effect, and, of course, we'd all know that the v stands for Vintage ;-)

Also, Sándor Bárány wrote to point me to a site which he finds exciting:

I've just spent the last few hours going through it, and it looks as though it has
everything we need to set up a proper chrooted build-environment for debian-s390.
Given a toolkit this rich would let us set up a verifyable "selfmaintaining" 
build-playground capable of rebuilding itself.

I got the idea about the chrooted playground from Ralf Flaxa on 
lsb-discuss@lists.linuxbase.org, where they are talking about 
how to build the proposed LSB-Test-Suite.

o Starting with the runtime system we currently try to build a development
  system, that will produce LSB compliant binaries. This is on our plate
  this week.

o Once we have the development system complete enough, we will rebuild
  the runtime and development system again using a process we call
  self-hosting, so bootstrapping yourself in 3 phases much like GCC does.

  1. A development system recompiles a development system from sources
  2. The resulting development system rebuilds itself
  3. The now clean (fixpoint!) development system rebuilds itself again
     and also all the other packages too.

     That's the process we use in building Caldera OpenLinux and that has
     proven to be very good to have a clean development system.

     Once we have doen this it will allow us to upload a clean source base
     to SourceForge and that was planned as the "visible" starting point.
     We did not want to upload something that can't rebuild itself and was
     just "hacked" together somehow. We believe that a good quality start
     is crucial to the success of it.

So the combination of "ThE" software to do the deb-source package-selection
and data-movement, and the (soon-to-come) "reconstructible building area" 
should give us a highly automatable, verifyable and auditable "build-daemon".

It's midnight here now, and it *was* an interesting week...
"Whatever you do will be insignificant, 
but it is very important that you do it."  == Mahatma Gandhi ==
Have a nice day ;-) Richard Higson mailto:richard.higson@gt.owl.de

Reply to: