Fwd: Re: SPARC Project Maintenance

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

 



 On 03/12/12 21:33, Dafydd Crosby wrote:
On Mon, Dec 3, 2012 at 2:17 PM, Bryce <bryce@xxxxxxxxxxxxxxxxxx> 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)
=--=
_______________________________________________
sparc mailing list
sparc@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/sparc

[Index of Archives]     [Fedora Users]     [Older Fedora Users]     [Linux ARM]     [ARM Kernel]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Triage]     [Coolkey]     [Yum Users]     [Tux]     [Big List of Linux Books]     [Yosemite Hiking & Camping]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux