lsbsi/gcc 3.4 mini-update

"Wichmann, Mats D" <[email protected]> Wed, 29 Dec 2004 14:09:12 -0800
Newsgroups gmane.linux.lsb.implementation
Message-ID <A06801158AE07847B27A52C1A074BC1D06DEFA0D@fmsmsx404.amr.corp.intel.com>
As I've reported earlier, I've been fiddling with building
the lsbsi under gcc 3.4 in preparation for LSB 3.  The base
work for this was checked in last week and earlier, but
as I'm not really working this week, a final set of=20
"clean" builds didn't happen until now.

I've kicked these off in odd moments, with these results
against current cvs:

2.1 tree - "current" gcc 3.3.5-based system
2.9 tree - "future" gcc 3.4.3-based system

To do a 2.9 build, you need to manually rename
entities/package.gcc34 to entities/package (save the old
version if you like), hand-edit lsbsiversion to say
2.9.0, run ./Configure, and use extras/entitycheck.py
to populate the source area.  That tool will report some
missing patches, those are in the patches/ subdirectory.
entitycheck still doesn't fetch local patches into the=20
source area, just copy those over.

IA64: 2.1 clean, 2.9 clean
x84_64: 2.1 clean, 2.9 clean
IA32: 2.1 clean, 2.9 fails with a segv in the
  install phase of glibc in lsbsi phase3.

I was going to kick these off on other machines like
ppc and 390, but all of the buildX machines of those
architectures are low on space and I don't want to
get rid of the stuff that is taking lots of space
on my own, I'll leave that for when Marvin gets back.

The IA32 failure has not been investigated, and=20
won't be (by me) this week.


Last week I also gathered notes on the latest package
versions for the si and appbat onto the wiki here:
http://www.linuxbase.org/LSBWiki/ToolsGroup

Note that the first-pass reference for what versions
are new was a Gentoo repository, so it's not necessarily
100% accurate.  By the time you read this, the situation
will have changed anyway, so I'm not going to worry
about it.  I believe what matters is gcc/glibc versions.