On 03/12/12 21:33, Dafydd Crosby wrote:
On Mon, Dec 3, 2012 at 2:17 PM, Bryce <bryce@zeniv.linux.org.uk mailto:bryce@zeniv.linux.org.uk> wrote:
On 03/12/12 20:20, Dafydd Crosby wrote: > Hello, > I've been told on the IRC channel that the SPARC project is looking > for a maintainer. I've got a SunBlade 2500 and experience building and > maintaining RPM's, so if someone could let me know what needs to get > done, I'd be happy to do it. > > -Dafydd Crosby Atm I'm loking into the fc18 build environment that would be used to bootstrap the whole fc18 build,.. there is a chunk of broken madness in the binutils ld.so which I'm bisecting atm, I might have that fixed or at least properly identified if I dunno what the answer to it is by tomorrow. Thers also something a bit odd going on with gcc which stops c++ being recompiled. glibc has a unprotected header (memcopy.h) that you need to fit a #ifndef _MEMCOPY_H, #define _MEMCOPY_H, #endif around. Then to get past a few other items you need to compile gcc statically,.. Later on, kernelwise there is a pita where an asumption is made that adressing is by 42bits when in actual fact it should be 48 leading to spurious kernel hangs,.. loads and loads of other 'close but not right' problems,.. I'm working through them but it's gonna be at least a week, possibly two, before I have a buildroot environment ready to bootstrap everything. (simplistic overview) Not to mention the pile of catch 22 chicken egg shared lib broblems. Joy. I also need to extricate a reasonably speced sparc into the community ring from the lab. (endless paperwork and trying to convince folk to authorise) as the sparcs that are currently used are looking somewhat long in the tooth compared to. There is a ton of other administrative paperpushing going on in the background that would make European beurocrats blush. It's unfortunately just been slow getting it moving 8( On the plus side I do have a static 2.7.2 gcc c compiler compiled up though I'm using that to attack the ld.so problem I mentioned above. Phil =--=Awesome! My machine's not exactly high-power, but I can throw it on Koji at least to get the ball rolling.
(slight correction to the above,.. not 42bit... 41 bits)
might need more time that I envisaged, glibc has a bit of work to be done to it when you compare it to whats in the fc18 repo for Intel architecture. Once I've enough to get a 1/2way sane environment going I'll punt that over to the tools folk to sift through and try and fix it up a bit better since glibc isn't my development niche.
(html table follows) x86_64 glibc (2.16-26.fc18) sparc glibc-2.16-26.1.fc18
ISO... ISO99... Total number of tests : 1776 Number of failed tests : 4 ( <1%) Number of skipped tests : 0 ( 0%) ISO11... Total number of tests : 1840 Number of failed tests : 4 ( <1%) Number of skipped tests : 0 ( 0%) POSIX... XPG3... Total number of tests : 4418 Number of failed tests : 281 ( 6%) Number of skipped tests : 158 ( 3%) XPG4... Total number of tests : 4463 Number of failed tests : 189 ( 4%) Number of skipped tests : 86 ( 1%) UNIX98... Total number of tests : 4696 Number of failed tests : 58 ( 1%) Number of skipped tests : 37 ( <1%) XOPEN2K... Total number of tests : 6168 Number of failed tests : 24 ( <1%) Number of skipped tests : 11 ( <1%) XOPEN2K8... Total number of tests : 5499 Number of failed tests : 19 ( <1%) Number of skipped tests : 4 ( <1%) POSIX2008... Total number of tests : 5692 Number of failed tests : 14 ( <1%) Number of skipped tests : 2 ( <1%)
DEBUG: ISO... DEBUG: ISO99... DEBUG: Total number of tests : 1776 DEBUG: Number of failed tests : 4 ( <1%) DEBUG: Number of skipped tests : 0 ( 0%) DEBUG: ISO11... DEBUG: Total number of tests : 22 DEBUG: Number of failed tests : 22 (100%) DEBUG: Number of skipped tests : 22 (100%) DEBUG: POSIX... DEBUG: Total number of tests : 2696 DEBUG: Number of failed tests : 3 ( <1%) DEBUG: Number of skipped tests : 0 ( 0%) DEBUG: XPG3... DEBUG: Total number of tests : 4418 DEBUG: Number of failed tests : 281 ( 6%) DEBUG: Number of skipped tests : 158 ( 3%) DEBUG: XPG4... DEBUG: Total number of tests : 4463 DEBUG: Number of failed tests : 189 ( 4%) DEBUG: Number of skipped tests : 86 ( 1%) DEBUG: UNIX98... DEBUG: Total number of tests : 4696 DEBUG: Number of failed tests : 59 ( 1%) DEBUG: Number of skipped tests : 37 ( <1%) DEBUG: XOPEN2K... DEBUG: Total number of tests : 6168 DEBUG: Number of failed tests : 25 ( <1%) DEBUG: Number of skipped tests : 11 ( <1%) DEBUG: XOPEN2K8... DEBUG: Total number of tests : 5499 DEBUG: Number of failed tests : 20 ( <1%) DEBUG: Number of skipped tests : 4 ( <1%) POSIX2008... DEBUG: Total number of tests : 5692 DEBUG: Number of failed tests : 17 ( <1%) DEBUG: Number of skipped tests : 2 ( <1%)
2 Extra tests
1000's of tests not run? why?
Not entirely sure whats going on here... sparc is running POSIX tests but the Intel side didn't?
One extra failure
One extra failure
One extra failure
Three extra failures
as for elfutils,.. the testsuite for 'elflint' fails spectacularly, fortunately I haven't come across anything that wants to use it in any anger so I've removed it from the sparc build until someone with far more ELF knowledge, (which would basically be anyone else), can figure out what it's issues are. I'm really hoping the errors it's spewing out are just alarmist and not deathly serious. The processor specific flag bit might well be down to me using a sparc T4. Oh well,..
<mock-chroot>[root@localhost tests]# make check-TESTS TESTS="run-elflint-self.sh" section [ 5] '.dynsym': symbol 45: st_value out of bounds section [36] '.symtab': symbol 128: st_value out of bounds *** failure in ../src/addr2line section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format *** failure in ../src/elflint section [ 5] '.dynsym': symbol 195: st_value out of bounds section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format section [38] '.symtab': symbol 474: st_value out of bounds *** failure in ../src/ld section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format *** failure in ../src/readelf section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format *** failure in ../src/strip loadable segment [7] flags do not match GNU_RELRO [1] flags section [36] '.gnu.attributes' has wrong flags: expected none, is section [36] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [36] '.gnu.attributes': unrecognized attribute format section [38] '.symtab': symbol 310: st_value out of bounds *** failure in ../libelf/libelf.so section [35] '.gnu.attributes' has wrong flags: expected none, is section [35] '.gnu.attributes' contains invalid processor-specific flag(s) 0x80000000 section [35] '.gnu.attributes': unrecognized attribute format *** failure in ../libdw/libdw.so FAIL: run-elflint-self.sh
Ugh,... when I get all the rpms for the minimal buildroot done (~130 pkgs though they in turn need dependant packages so more like 600) I'll turn those over to Dennis and co. to see about importing them into a koji instance somewhere and then start the long slog of hand cranking the remaining rpms through the system. though I'll bet the farm on a lot of them not compiling happily at all for sparc. Certainly there is a pile of hurt to work through for stuff like rpm/filesystem.
The real fun will start when we move onto Fc18's anaconda/silo, that is a whole new pit of snakes though I've a lot of the kinks already worked out.
Suffice to say thers a lot of work,... not hard per se,.. just a lot of grunt work.
Phil (desperately in need of sleep) =--=
-
Bryce