On 04/20/2018 03:44 PM, René Rebe wrote: > Well, remember, I only went down with binutils / gcc versions because latest > binutils/ld segfaults linking newer glibcs: > https://twitter.com/renebln/status/984741114757439488 > > #2 in bfd_malloc at ../../bfd/libbfd.c:193 > #3 in _bfd_elf_strtab_finalize at ../../bfd/elf-strtab.c:368 > #4 in _bfd_elf_assign_file_positions_for_non_load at ../../bfd/elf.c:6318 > #5 _bfd_elf_write_object_contents at ../../bfd/elf.c:6354 > #6 in bfd_close at ../../bfd/… > > This is how I ended up downgrading binutils, glibc and gcc until I had a user-land > that built, … (yes, I neglected t2/sparc* support the last years, sorry for that) I remember there was recently an issue with glibc and 32-bit sparc userland that the Gentoo folks saw. I don't remember what it was though. We don't have any binutils problems on a 64-bit userland in Debian that I know of. Usually, James Clarke and Eric Botcazou are very fast fixing those issues in binutils or gcc. binutils had several regressions with the first 2.30 versions but all that stuff was fixed in the latest 2.30 branch and glibc builds fine. So, if you have something reproducible for binutils, please file it in the upstream bug report tracker and CC them and me. Also, we have a fast SPARC-T5 porterbox running Debian sparc64 unstable which is used by many upstream developers (qemu, gcc, binutils, FPC and so on) and those people constantly test their stuff on this machine. Thus, lots of stuff was already fixed for sparc64. Though there can always be surprises, especially in binutils. Oracle themselves is focusing on the 64-bit SPARC userland, although I don't know how busy they are at the moment. In general, I would recommend you joining #debian-ports on OFTC and #gentoo-sparc on Freenode and #sparc on Freenode. There are lots of knowledgeable people around who also usually know about the latest regressions or previous issues. >> So, in case you are unable to track down the issue in the kernel, try a newer >> toolchain and the latest version of binutils (2.30 + branch updates). > > Speaking of “updates”, if you have a patch for that segfault, … > But today is your lucky, as my latest financing opensource work by YouTube > videos (http://youtube.com/renerebe) shows some results, I now rebuild > latest t2/svn:HEAD toolchain and re-build the Linux kernel for you (as > the binutils/ld crash happened with glibc, I only need to toolchain for > the kernel build): > > # scripts/Build-Target -cfg sparc64 -job 0-binutils > == 13:34:33 =[0]=> Building develop/binutils [2.30 9.0-svn]. > # scripts/Build-Target -cfg sparc64 -job 0-gcc > == 13:36:00 =[0]=> Building develop/gcc [7.3.0 9.0-svn]. > # scripts/Build-Target -cfg sparc64 -job 1-linux > == 13:42:19 =[1]=> Building base/linux [4.16.3 9.0-svn]. > > Waiting for the kernel to finish on my more Epyc CPU and then > rsync and reboot. So maybe less than an hour or so ;-) I just checked the latest build logs. The glibc testsuite recently failed for 2.27 but did not fail for a previous 2.27 build: FAIL: https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=sparc64&ver=2.27-3%2Bb1&stamp=1523840708&raw=0 PASS: https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=sparc64&ver=2.27-3&stamp=1522364505&raw=0 There was also a userland memory corruption with kernel 4.14+ which got fixed with 4.16-rc6. After upgrading the kernel, many packages built fine again but surprisingly not glibc. I should probably poke glibc upstream after triggering another rebuild of glibc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@xxxxxxxxxx `. `' Freie Universitaet Berlin - glaubitz@xxxxxxxxxxxxxxxxxxx `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
