Arch linux for Sparc Ultra2

cb88 · 2009-11-02 22:09:02

I was able to get the cross compiler working and got a few packages built

I am currently stuck at embutils since apparently the wrong options are getting passed to its configure script I might be able to fix it myself I don't know

Angel_LB · 2009-12-05 14:48:40

Ok guys, I could finally get started this week, having found the missing components

Project name: SPArch (SPARC.. Arch.. woot )
Host system: SunFire v100, 2x40gb HD, 512mb of RAM, 500mhz UltraSPARC IIe CPU
Steps:
a) Setting up the server (Get it to see disks, CDROM and boot off them) -- DONE!
b) Install a primary host (Debian 5.03 retained) -- DONE!
c) Build the LFS toolchain, used to build the final install in LFS, while keeping an eye on
CLFS-sparc, to catch any special steps a SPARC processor would need.
d) Use this toolchain to build the ABS system and use it for makeworld.
e) Enjoy!

Ok this is fairy tail if it all works right just out of the box, for sure. I expect some bumps on the road, of course.
Right now steps A and B are done here, so I will have a look at C.

Once C is done and the tools are all there, I may chose to start my two other servers to give a hand in the compiling part, cloning the working hosts for this process.

I wonder if I should include -ALL- packages (X, ATI drivers, etc. ?) in this port, as most of the people will certainly only use it for servers.
Any idea?

References:
LFS: http://www.linuxfromscratch.org/lfs/vie … treqs.html
CLFS-SPARC64: http://cross-lfs.org/files/BOOK/1.1.0/C … e-hostreqs

Last edited by Angel_LB (2009-12-06 17:44:37)

Angel_LB · 2009-12-06 17:44:17

At first glance, the packages offered by Debian 5.03 are usable, version-wise, compared to the requirements of LFS. That's a good start.
I am currently building the toolchain, with an SBU of 17m36sec.
I've seen slower, but I guess an i7 would do much better

I am however puzzled about the '--disable-multilib' option of gcc. I guess it's for 32bit-over-64bit and I should not care much about it so I left it -- everything should be 64bit anyway.

interphase · 2010-03-28 13:56:10

any news, Angel_LB?

I've also started to build arch for sparc64, but with a different approach:
- Create a toolchain (glibc, zlib, binutils, gcc) using ABS & makepkg from within an untouched gentoo chroot. <- I'm currently compiling them
- Compile pacman to a different chroot.
- Install the toolchain compiled earlier into this chroot.
- Install abs.
- Compile all other packages.

What do you think, will it work?

EDIT:
to get the toolchain to compile, I've edited the PKGBUILDs like this:

sed -i.old 's/i686/sparc64 i686/' PKGBUILD

and

sed -i.old 's/depends/#depends/' PKGBUILD; sed -i.old 's/makedepends/#makedepends/' PKGBUILD

Last edited by interphase (2010-03-28 13:59:45)

Angel_LB · 2010-03-28 15:20:29

@interphase: Sadly not. I went into a bump and stalled while I needed more time on some other tasks (read: work, on some other platform..)

Your plan seems nice, using ABS from the start is what I had in mind as well, I needed a toolchain first. As I have no prior experience with SPARC, I wanted to follow a guideline and LFS seemed a good start. What I see as a potential problem is the fact that LFS is cross-compiling at first (from 32-bit i386) so some hints might not be good compared to a SPARC-to-SPARC compiling.

I don't know about your edits. Do you mean you edit those for the toolchain? If so, ok, but it needs to stay once you start tho 'make world'. What you might need is some edit of makepkg.conf to add architecture compile flags and support (i686, x86_64, SPARcII ?) and maybe pacman.conf too

As I said I ran out of free time for this project, but my V100 are sitting at arm's length above in front of me, ready to go once I'm done with those other tasks (namely VBS self-bootcamp and W7 cert. A shame, I tell you....)

I think you idea of using ABS and makepkg on the gentoo itself is bright. I will try and do the same on my Lenny (Debian 5.03) instead of going LFS.

Do you have any reference on build flags for UltraSPARC? LFS might not be a bad place, I need to read furthur down the document and see what is suggested for the last step, once the build occurs witin SPARC environment.

Thanks for the post, keep us posted too

interphase · 2010-03-28 15:38:39

Angel_LB wrote:

I don't know about your edits. Do you mean you edit those for the toolchain? If so, ok, but it needs to stay once you start tho 'make world'. What you might need is some edit of makepkg.conf to add architecture compile flags and support (i686, x86_64, SPARcII ?) and maybe pacman.conf too
Do you have any reference on build flags for UltraSPARC? LFS might not be a bad place, I need to read furthur down the document and see what is suggested for the last step, once the build occurs witin SPARC environment.

well, those edits are obviously needed. if we're not doing those, then all the builds will fail (in the PKGBUILD only i686 and x86_64 are stated as valid architectures).
and there are no pacman-packages installed (obviously), so we need to pretend those pkgs dont have any deps (second + third sed).

as for the build flags, I'm using:

makepkg.conf wrote:

CFLAGS="-mtune=v8 -O2 -pipe"
CXXFLAGS="-mtune=v8 -O2 -pipe"

my ultra2, ultra5 and blade1000 all have at least sparcv8. but thats just a test.
as for the 'real' thing, I dont know. maybe compile all pkgs as 32bit ones (-m32)?

sadly, I've also "bumped" into a glibc bug trying to do it w/o the gentoo chroot now, ie. directly from the debian itself.

I'll keep you nevertheless posted!

interphase · 2010-03-28 16:27:01

OK, as for now, glibc fails:

In file included from ../include/tls.h:6,                                                                         
                 from ../sysdeps/unix/sysv/linux/sparc/sparc64/sysdep.h:29,                                       
                 from <stdin>:1:                                                                                  
../nptl/sysdeps/sparc/tls.h:70:3: error: #error "TLS support is required."                                        
make[2]: *** [/home/elite/build/glibc/src/glibc/glibc-build/tcb-offsets.h] Error 1                                
make[2]: Leaving directory `/home/elite/build/glibc/src/glibc/csu'                                                
make[1]: *** [csu/subdir_lib] Error 2                                                                             
make[1]: Leaving directory `/home/elite/build/glibc/src/glibc'                                                    
make: *** [all] Error 2                                                                                           
==> ERROR: Build Failed.                                                                                          
    Aborting...                                                                                                   
elite@fullmoon:~/build/glibc$

After analyzing the fragment which is responsible for TLS:

elite@fullmoon:~/build/glibc/src/glibc/sysdeps/sparc/sparc64/elf$ gcc -o conftest.bin conftest.s
conftest.s: Assembler messages:
conftest.s:22: Error: Architecture mismatch on "ldx".
conftest.s:22:  (Requires v9|v9a|v9b; requested architecture is sparclite.)

A bit of googling revealed a possible workaround:
CFLAGS+="-mcpu=ultrasparc"
which just tells gcc that we're compiling for ultrasparc (not turbosparc or something else)

now trying with the new CFLAGS set in makepkg.conf...
keep your fingers crossed (its already beyond that TLS part)

EDIT: didnt work, but as per http://www.mail-archive.com/lfs-support … 00132.html, now trying to compile with --host=sparcv9-unknown-linux-gnu

Last edited by interphase (2010-03-28 16:36:23)

Angel_LB · 2010-03-28 16:30:49

interphase wrote:

well, those edits are obviously needed. if we're not doing those, then all the builds will fail (in the PKGBUILD only i686 and x86_64 are stated as valid architectures).
and there are no pacman-packages installed (obviously), so we need to pretend those pkgs dont have any deps (second + third sed).

Yes, you are right, I wrote too fast, so to speak What I meant was to put back the depends/makedepends once you're ready to go and build everything. Adding the sparc64 as an architecture is a must, I agree.

interphase wrote:

as for the build flags, I'm using:
makepkg.conf wrote:
CFLAGS="-mtune=v8 -O2 -pipe"
CXXFLAGS="-mtune=v8 -O2 -pipe"

I ran into this (gcc SPARC options) which might help as well.

interphase wrote:

as for the 'real' thing, I dont know. maybe compile all pkgs as 32bit ones (-m32)?

Well it depends on what we have in mind. I wanted a native 64bit system, but both could be great
I could build the Sparc64 while you handle a Sparc32 repo.

All in all, it should go down to a makepkg.conf setup forcing 32bit or 64bit while the PKGBUILD shouldn't be changed, much like the current i686/x86_64 architectures handling. Once the toolchain is build, sync'ing the whole ABS content and a massive
sed -i.old "s/arch=(/arch=('sparc64' 'sparc32'/" PKGBUILD (so to add sparc support while leaving whatever intel is already there) should be all what is needed to get this thing going.

Well, hopefull thinking

Some other people have an opinion?

Btw, I suggest you review some of those PKGBUILDs because given your sed command earlier, I think architecture support might be broken, unless your command was typed on the spot here in the board and not copy/pasted from actual code in a script.

command: sed -i.old 's/i686/sparc64 i686/' PKGBUILD
gives me: arch=('sparc64 i686') *watch the missing two inner (')

Command: sed -i.old "s/'i686'/'sparc64' 'i686'/" PKGBUILD *watch the outer (') replaced by (")
gives me: arch=('sparc64' 'i686')

interphase wrote:

sadly, I've also "bumped" into a glibc bug trying to do it w/o the gentoo chroot now, ie. directly from the debian itself.

Right on the nail, that was my bug too. I tried rebuilding gcc with the '--disable-multilib' option (or removing it..), as glibc was complaining about something having to do with this (so fas as memory serves) It's a little clouded for me, been too long since I looked at that.

Looking at my notes, I was at...

Project SPArch wrote:

gcc-4.4.1
added to configure: --enable-tls
remove to configure: --disable-threads
glibc-2.10.1
error: #error "TLS support is required."
Seems --enable-tls need be added to GCC...
echo "CFLAGS += -march=sparc64 -mtune=native" > configparms
added to configure: --with-tls --with-__thread

then nothing...

Last edited by Angel_LB (2010-03-28 16:35:27)

interphase · 2010-03-28 16:43:26

Angel_LB wrote:

interphase wrote:
well, those edits are obviously needed. if we're not doing those, then all the builds will fail (in the PKGBUILD only i686 and x86_64 are stated as valid architectures).
and there are no pacman-packages installed (obviously), so we need to pretend those pkgs dont have any deps (second + third sed).
Yes, you are right, I wrote too fast, so to speak What I meant was to put back the depends/makedepends once you're ready to go and build everything. Adding the sparc64 as an architecture is a must, I agree.
interphase wrote:
as for the build flags, I'm using:
makepkg.conf wrote:
CFLAGS="-mtune=v8 -O2 -pipe"
CXXFLAGS="-mtune=v8 -O2 -pipe"
I ran into this (gcc SPARC options) which might help as well.
interphase wrote:
as for the 'real' thing, I dont know. maybe compile all pkgs as 32bit ones (-m32)?
Well it depends on what we have in mind. I wanted a native 64bit system, but both could be great
I could build the Sparc64 while you handle a Sparc32 repo.
All in all, it should go down to a makepkg.conf setup forcing 32bit or 64bit while the PKGBUILD shouldn't be changed, much like the current i686/x86_64 architectures handling. Once the toolchain is build, sync'ing the whole ABS content and a massive
sed -i.old "s/arch=(/arch=('sparc64' 'sparc32'/" PKGBUILD (so to add sparc support while leaving whatever intel is already there) should be all what is needed to get this thing going.
Well, hopefull thinking
Some other people have an opinion?
Btw, I suggest you review some of those PKGBUILDs because given your sed command earlier, I think architecture support might be broken, unless your command was typed on the spot here in the board and not copy/pasted from actual code in a script.
command: sed -i.old 's/i686/sparc64 i686/' PKGBUILD
gives me: arch=('sparc64 i686') *watch the missing two inner (')

Command: sed -i.old "s/'i686'/'sparc64' 'i686'/" PKGBUILD *watch the outer (') replaced by (")
gives me: arch=('sparc64' 'i686')
interphase wrote:
sadly, I've also "bumped" into a glibc bug trying to do it w/o the gentoo chroot now, ie. directly from the debian itself.
Right on the nail, that was my bug too. I tried rebuilding gcc with the '--disable-multilib' option (or removing it..), as glibc was complaining about something having to do with this (so fas as memory serves) It's a little clouded for me, been too long since I looked at that.
Looking at my notes, I was at...
Project SPArch wrote:
gcc-4.4.1
added to configure: --enable-tls
remove to configure: --disable-threads
glibc-2.10.1
error: #error "TLS support is required."
Seems --enable-tls need be added to GCC...
echo "CFLAGS += -march=sparc64 -mtune=native" > configparms
added to configure: --with-tls --with-__thread
then nothing...

well, see my other post for the workaround (the one with --host=sparcv9...), it seems to compile now

and about those missing quotes...I don't care for the moment, because it works for me

Angel_LB · 2010-03-28 17:01:28

previous link wrote:

I get the impression that the 32-bit build needs --host=sparcv9-unknown-linux-gnu
which ought to pass -mcpu=ultrasparc -Wa -Av9a to gcc.

You are building a 32bit toolchain from a 64bit processor? This is what it seems to imply. The UltraSPARC II is a native 64bit architecture, thus I might not need this specific line, although if should not harm to tell what system is building the code.

Taking this into IM.

Angel_LB · 2010-03-28 17:34:42

Well thanks for pointing to me that Debian SPARC support has a 32bit userland. This might be the cause for my trouble as I though it was all 64bit (not only the kernel)

chris_debian · 2010-03-28 18:23:54

Hi, guys!

As a former Sparc user (32 and 64 bit), I'm keen to see how this develops. I've been itching to buy a Sparc again.....heading to eBay, now :-)

Cheers,

Chris.

interphase · 2010-03-28 19:19:06

@chris_debian: hey, nice to see that there are actually other people who want a sparc port of archlinux

so far, I've built zlib+glibc+binutils out of my debian and tomorrow (CET) I'll head over to gcc

wish me luck

chris_debian · 2010-03-28 19:22:22

Best of luck!

Chris.

chrisb · 2010-03-28 21:21:55

I have 2 fully populated E450 sun machines currently running gentoo and online 24/7
I can help out

interphase · 2010-03-29 16:57:09

@chrisb: that would be nice, cause here I only have a u5, u2 & my blade1000 (which I dont touch since it's my primary workstation)

I'll upload the next days a "build environment" (pacman, abs and makepkg for sparc64) for arch, so we can all compile

P.S: since these GNU (GCC) mirrors suck (I get like 6kb/s ) it'll take some more time...that sucks

chrisb · 2010-03-29 20:48:59

I'll write a script to automate the build of packages
Will they be uploaded anywhere?
I'm new to Arch, but have been using Gentoo for a long time
It wont be a problem

interphase wrote:

P.S: since these GNU (GCC) mirrors suck (I get like 6kb/s ) it'll take some more time...that sucks

No where else you can upload?
you run a web or ftp server I can directly get the file from?

Last edited by chrisb (2010-03-29 22:50:42)

chrisb · 2010-03-31 20:55:19

interphase wrote:

mirrors suck (I get like 6kb/s ) it'll take some more time...that sucks

That must be pretty slow

interphase · 2010-04-06 12:03:20

@chrisb, its slow, but fourtanetly we've upgraded and now I get 100x the 6kb/s

but I'm not at home currently, next week I'll go on with this
got stuck at gcc currently...ld doesnt want to link GMP with GCC, but I'll try to figure that out sometime.

chrisb, we are currently at some trial-and-error stage, still with the toolchain, so well...automated build scripts aren't currently of much use.
however, when we have the toolchain, we can massively start building all pkgs - automated. that's where you could come in (and a friend of mine said I could use his E420R so we could split the work)

I'll keep you all posted and thanks for the help so far...

Bomb@ · 2010-04-06 15:48:14

Hey,

i have a UltraSpace 10, 1gb Ram + 450Mhz with a DebianSparc, i would like to change to Arch, and i have time to build some PKGBUILD´s for ArchSparc

The mashine run´s 24/7 and i can upload it to a root server with unlimited 100mb/s traffic.

So Long

interphase · 2010-04-06 17:25:01

hey bomb@

I'm still surprised how many people actually _want_ arch for sparc...well, but see my previous post, at this stage, its kinda trial-and-error (for the toolchain), but hopefully, in some weeks you, chrisb, Angel_LB(?) and me can start building all those other packages

btw, the official name for the project is SPArch (see Angel_LB's post at the beginning of the page)

chris_debian · 2010-04-07 21:58:13

Hi, guys!

I was looking for an Ultra 5 and have ended up with two (at no cost)! I need to throw some RAM into one or both of them as I've got 128megsx6 waiting to be used. I'll try to do this tomorrow and then install something useful on it (probably GNU/Debian).

What's the state-of-play with the SPArch work?

Cheers,

Chris.

chrisb · 2010-04-08 03:22:33

interphase told me he wont be back until Monday

chris_debian · 2010-04-24 08:05:07

Anyone got an ISO I can try, my new Ultra 5 is ready and waiting to test.

Cheers,

Chris.

interphase · 2010-04-24 08:24:31

soo..sorry for the long 'downtime', but I was busy with other things
anyways:
http://www.multiupload.com/H7836ZWUYQ - SPArch Build Tools (includes the ABS + pacman and glibc, binutils, zlib, linux-headers as .pkgs)

have fun

PS: I'm stuck at compiling gcc, if you have some suggestions, please share them with us!

Arch Linux

#26 2009-11-02 22:09:02

Re: Arch linux for Sparc Ultra2

#27 2009-12-05 14:48:40

Re: Arch linux for Sparc Ultra2

#28 2009-12-06 17:44:17

Re: Arch linux for Sparc Ultra2

#29 2010-03-28 13:56:10

Re: Arch linux for Sparc Ultra2

#30 2010-03-28 15:20:29

Re: Arch linux for Sparc Ultra2

#31 2010-03-28 15:38:39

Re: Arch linux for Sparc Ultra2

#32 2010-03-28 16:27:01

Re: Arch linux for Sparc Ultra2

#33 2010-03-28 16:30:49

Re: Arch linux for Sparc Ultra2

#34 2010-03-28 16:43:26

Re: Arch linux for Sparc Ultra2

#35 2010-03-28 17:01:28

Re: Arch linux for Sparc Ultra2

#36 2010-03-28 17:34:42

Re: Arch linux for Sparc Ultra2

#37 2010-03-28 18:23:54

Re: Arch linux for Sparc Ultra2

#38 2010-03-28 19:19:06

Re: Arch linux for Sparc Ultra2

#39 2010-03-28 19:22:22

Re: Arch linux for Sparc Ultra2

#40 2010-03-28 21:21:55

Re: Arch linux for Sparc Ultra2

#41 2010-03-29 16:57:09

Re: Arch linux for Sparc Ultra2

#42 2010-03-29 20:48:59

Re: Arch linux for Sparc Ultra2

#43 2010-03-31 20:55:19

Re: Arch linux for Sparc Ultra2

#44 2010-04-06 12:03:20

Re: Arch linux for Sparc Ultra2

#45 2010-04-06 15:48:14

Re: Arch linux for Sparc Ultra2

#46 2010-04-06 17:25:01

Re: Arch linux for Sparc Ultra2

#47 2010-04-07 21:58:13

Re: Arch linux for Sparc Ultra2

#48 2010-04-08 03:22:33

Re: Arch linux for Sparc Ultra2

#49 2010-04-24 08:05:07

Re: Arch linux for Sparc Ultra2

#50 2010-04-24 08:24:31

Re: Arch linux for Sparc Ultra2

Board footer