Quick status update on sparc64
Hi!
Over the past weeks, we have made substantial progress in catching up
with the build queue and the number of packages which are up-to-date
in the sparc64 port are now over 8400 which means we have built more
than 700 packages since I started my thread with the subjet
"Resurrecting Debian on SPARC" on September, 15 2015.
One important factor is an additional buildd machine, a Sun T2000,
which is hosted by Harka Gyozo at the University of Pécs in Pécs,
Hungary. Thanks, Harka! Helge Deller, the main porter and buildd
maintainer, for Debian's hppa (PA-RISC) port, helped in setting
up a total of five buildd instances on Harka's machine (andi1
through andi5) which helped to use the machine more efficiently.
Plus, Helge is now registered as a wanna-build (Debian's package
build database) which means he can trigger binNMUs and rebuilds
on sparc64 as well. In order for Helge to be able to solve
problems with the buildds, he has also been granted access to
the sparc64 buildds which helps reducing my workload. Thanks, Helge!
Furthermore, I managed to fix several packages that were failing to
build by completely disabling the gold linker on sparc64. As further
research has shown, gold currently creates defect binaries due to
the fact that it does not fully implement the specification for
ELF binaries on SPARC.
To be more precise, it lacks support for the so-called dummy symbol
"STT_SPARC_REGISTER" which the linker uses to define how either of the
four global CPU registers %[2367] are used. Since gold does not
understand that STT_SPARC_REGISTER is a dummy symbol and not to
be associated with an actual offset address, it sets the address
field associated with the symbol to zero (while only 2, 3, 6 or
7 are valid values) which produces a defect object file which
later produces the known error message on consecutive linker
runs [1]:
Only registers %g[2367] can be declared using STT_REGISTER
The problem with this bug is that currently gold's internal
representation of ELF objects has no way to accommodate these
dummy symbols. This means, that gold needs additional work
on its generic, non-target-specific code which will naturally
take a bit longer. Thus, until the associated PR [1] in gold
has been fixed, it's the safest option disable gold on sparc*
altogether. By not using gold, we won't loose anything really
except that the whole linking process takes longer as gold
has been designed with link-time reduction in mind. I am not
sure though whether there are actually any differences in the
resulting binaries though.
Anyway, we have now 8 buildd processes which are crunching
through the build queue now and with some luck, we might
be able to catch up with architectures like hppa in 1-2
more months unless there are more packages that need
additional manual work.
Future plans could see a sparc64 installation image for
Debian. Helge Deller has already this for hppa and he
will certainly lend his expertise and help us to create
fresh installation images for sparc64 so that all SPARC
machines still running the 32-bit port of Debian SPARC
can be upgraded to the 64-bit sparc64 port.
Cheers,
Adrian
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19019
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: