On Tue, Nov 10, 2015 at 4:10 PM, John Paul Adrian Glaubitz <[email protected]> wrote: > 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.
Good work, John! Out of curiosity, the STT_REGISTER issue is caused by ABI and is not Linux-specific, so Solaris and *BSD have it too, right? Artyom -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
