Re: Quick status update on sparc64
On Tue, Nov 10, 2015 at 4:10 PM, John Paul Adrian Glaubitzwrote: > 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
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913