Re: Resurrecting Debian on SPARC
Good morning,
In my efforts to help this along I am trying to set up a chroot
environment for testing. I have tried multistrap and sbuild setup from
the debian wiki and from various places found whilst googling. To date
I've not had any success.
Is there a HOW-TO somewhere for setting up a chroot environment for the
purpose of testing/porting portions of sid?
Am I even asking the right question(s)?
Rod
On 9/15/2015 5:07 AM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> I was wondering how many here are still interested in the Debian
> SPARC port?
>
> In the past weeks, I have invested some efforts to revive the sparc64
> port a bit and managed to get at least gcc-5 compile and work through
> the build queue a bit. Rod Schnell, a user from the US, kindly donated
> an UltraSPARC IIIi for use which I set up as an additional buildd and
> porterbox (Hostname: raverin).
>
> Currently, there are some packages left like mozjs that need manual
> porting before they will compile on sparc64. Furthermore, there are
> a number of packages which fail with weird linker errors [1]:
>
> =======================================================================
>
> gcc -DHAVE_CONFIG_H -I. -I../../../usbhid-dump/src -I..
> -I/«PKGBUILDDIR»/usbhid-dump/include
> -I/«PKGBUILDDIR»/build-deb/usbhid-dump
> -I/«PKGBUILDDIR»/build-deb/usbhid-dump/include -DNDEBUG
> -D_FORTIFY_SOURCE=2 -Os -Wall -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/include/libusb-1.0 -c -o usbhid-dump.o
> ../../../usbhid-dump/src/usbhid-dump.c
> /bin/bash ../libtool --tag=CC --mode=link gcc -Os -Wall -g -O2
> -fstack-protector-strong -Wformat -Werror=format-security
> -I/usr/include/libusb-1.0 -Wl,-z,relro -o usbhid-dump usbhid-dump.o
> ../lib/libuhd.la -lusb-1.0
> libtool: link: gcc -Os -Wall -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/include/libusb-1.0 -Wl,-z -Wl,relro -o
> usbhid-dump usbhid-dump.o ../lib/.libs/libuhd.a -lusb-1.0
> /usr/bin/ld: //lib/sparc64-linux-gnu/libudev.so.1: Only registers
> %g[2367] can be declared using STT_REGISTER
> //lib/sparc64-linux-gnu/libudev.so.1: error adding symbols: No such file
> or directory
> collect2: error: ld returned 1 exit status
> make[6]: *** [usbhid-dump] Error 1
>
> =======================================================================
>
> And some just segfault during build [2]:
>
> =======================================================================
>
> /usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
> man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam
> man.authors.section.enabled 0 --stringparam
> man.copyright.section.enabled 0 --stringparam systemd.version 226 --path
> './man:../man' ../man/custom-man.xsl ../man/bootup.xml
> make[4]: *** [man/bootup.7] Segmentation fault
> Makefile:21248: recipe for target 'man/bootup.7' failed
> make[3]: *** [all-recursive] Error 1
>
> =======================================================================
>
> Anyone here willing to join the efforts to fix the sparc64 port or
> even resurrect the 32-bit SPARC port which was recently removed from
> Debian?
>
> I think it might be actually a good idea to resurrect the 32-bit
> port and add it to Debian ports since sparc32 seems to be a in
> a better shape regarding kernel and toolchain support.
>
> Cheers,
> Adrian
>
>> [1]
> https://buildd.debian.org/status/fetch.php?pkg=usbutils&arch=sparc64&ver=1%3A007-4&stamp=1441551102
>> [2]
> https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=sparc64&ver=226-1&stamp=1442141223
>
Reply to: