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.