9:36 p.m.
On 03/12/12 21:33, Dafydd Crosby wrote:
On Mon, Dec 3, 2012 at 2:17 PM, Bryce <bryce(a)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)
=--=