Alex McWhirter | 29 Jan 00:06 2016

Official SPARC64 Port

I'm going to try to keep all future discussion of this in this thread
for now on.

If you've kept up with the sparc list lately (seems like very few people
do these days) i've been working on fixing up the sparc port to include
a pure 64bit port. Basically here is where we stand in regard to the
completion of this project.

    sparc32: Done
    sparc32-multilib: Done
    sparc64: Done
    sparc64-multilib: Done

    sparc32: Booting
    sparc32-multilib: Booting
    sparc64: Booting + Fairly Well Tested
    sparc64-multilib: Booting

Install ISO: TODO

The profiles have all been reworked quite a bit, which is why i feel the
need to test all of them thoroughly.

It's also worth noting that at this moment i am not an official Gentoo
developer, although i am working towards having that goal met in the
very near future. So at this point it's possible all of my work is junk
as no one has really looked over it but me :p, so keep that in mind.
That being said, i am posting this from an Ultra 45 with ZFS and a
(Continue reading)

Alex McWhirter | 27 Jan 00:30 2016

LIB32 or LIB?

If using symlink_lib=no, shoud 32bit libraries be placed in lib32 or
lib? If we use lib32 we need to modify the base layout to compensate for

Mike Frysinger | 24 Jan 17:30 2016

Re: unsubscribe

On 24 Jan 2016 10:37, Daniel wrote:
> unsubscribe

sorry, but that's not how it works.  please review the docs:
Alex McWhirter | 19 Jan 19:47 2016

GLIBC Issues

In many places im seeing LD output this in the configure script of a
multilib glibc ebuild. This is configuring 32bit glibc on a 64bit host.

sparc:v9 architecture of input file `somefile' is incompatible with
sparc output

So it looks like LD is working right, but GCC is still compiling 64bit.
Or it could be G++ compiling 64bit as i don't see a -m32 flag set for
it? I seem some references to G++.

Alex McWhirter | 18 Jan 06:49 2016

Pure SPARC64 Port (Was Re: Sparc64 OpenSSL)

On 01/17/2016 10:53 AM, Mike Frysinger wrote:
> sure, but you said "should we not remove support for sparcv8 and
> older". you can't drop support for them w/out breaking the
> embedded/cross case. 
I guess what i meant was don't release stage3's and ISO's for older
archs, but in reality we are already doing that as the current SPARC
port requires sparcv9 because of the kernel.
> correct, but we don't support this case with any other arch. you don't
> do migration between them, you pick during initial download. this is
> why we have x86 & amd64 stage3 tarballs, s390 & s390x tarballs, ppc &
> ppc64 stage tarballs. we'd simply have sparc & sparc64 state3 tarballs.

> here's where naming gets tricky. we do not want a new KEYWORD. i think
> ppc/ppc64 was a mistake. we don't have mips/mips64 (and mipsn32) and
> they've been fine. same for amd64 & x32. i.e. we just treat it as a
> new ABI. as for profiles, we can create new subdirs under sparc where
> it makes sense. so we'd take all the sparc32-specific stuff out and
> move it to a new subdir, and create a sparc64 subdir to hold the new
> specific bits. profiles/arch/sparc/ - common stuff here sparc32/ -
> sparc32 stuff here sparc64/ - sparc64 stuff here
> profiles/default/linux/sparc/ - common stuff here sparc32/ - sparc32
> stuff here sparc64/ - sparc64 stuff here any time a package needs to
> change its behavior based on 32-bit/64-bit, it should be doing compile
> time tests.

That's an interesting viewpoint and adding a keyword generally creates
more work for everyone. In the case of a single sparc profile with
various 32bit / 64bit sub-profiles how do you handle the case of an
application that requires 32bit and only 32bit? Wine would be a good
example. On x86 we have use flags and a use expand for ABI_X86, and wine
(Continue reading)

Alex McWhirter | 9 Jan 03:34 2016

Reviving the SPARC port a bit...

The sparc port seems to be aging, in particular the installation ISO and
stage 3 archives. I'd like to propose a few things and get some opinions.

1. We need new stage 3 libraries and installation ISO's. That's probably
a given.

2. We need a stage 3 with a 64bit userland. Thanks to Oracle, we now
have kernel / driver support for many newer sparc boxes that can utilize
large amounts of ram and don't see much of a performance reduction by
running 64bit code. I don't think killing the 32bit userland single-lib
archive is a good idea as some people probably see much better
performance on older boxes. However, we could set the multilib profile
to default to 64bit with 32bit backwards compatibility. We could also
just make new stage 3 profile / profiles.

3. Maybe we should consider finalizing the multilib profile, and make it
look more like the x86 profile as far as functionality is concerned.

I figure there aren't a lot of people around here, but i am willing to
start doing all of this by myself. Who knows, maybe we can attract a few
more developers if the port gets a bit more aligned with the rest of
gentoo. I have quite a few machines at my disposal. A few V215's,
T1000's, M4000's, T5120's, Netra X1's, and probably a few more that i
can't think of at the moment. I plan on setting myself up a few build
servers, anyone else who wants to help is welcome to an account on them.

jwayres | 23 Dec 21:29 2015

Fw: new important message



New message, please read


jwayres <at>

dmm | 7 Jun 00:12 2015

RE: Fwd: Sparc Arch status

Jack Morgan,

Thanks for offering your plan for gentoo-sparc. I'm interested in
gentoo-sparc as well and I'd like to help if I could. Regarding the
points you brought up, here are my thoughts.

(1) Bugzilla

In Feb. 2015 I was looking for sparc related issues to resolve and I
found bug #532088, a SIGBUS crash in openvpn caused by an LZO bug. I
worked with the LZO author to fix the problem and the fix is included in
lzo version 2.09. I created a gentoo bug to describe the issue and the
fix (upgrade to 2.09), #539760. It would be great to get LZO upgraded to
2.09 because LZO is currently completely broken on sparc.

(2) Installation

The documentation seems to be in good shape, except for a couple issues
I identified:

a) The only filesystem tools that seem to be included on the live cd are
e2fsprogs. This isn't really a problem except that the handbook
describes the other filesystems such as xfs, js, etc. Is there a reason
the other tools are omitted? If so, we should probably not present them
as options in the handbook.

b) The other issue I saw was that the handbook recommends -march=native
when gcc doesn't even seem to support any "-march" flags on
sparc, instead using "-mcpu" or "-mtune". I believe "-mcpu=native"
should work similarly.

As for the live cd itself I was unable to create a working system from
the current image. As soon as I upgrade glibc from what's in the current
stage3 tarball to the latest stable I get lots of "wait_for: No record
of process 0" errors when running programs, particularly portage. This
was the case compiling glibc with the gcc 4.7.x included in the
current stage3 and with the latest stable 4.8.4.

I'm not sure what the exact problem is. It may be related to the age of
the stage3, currently from 2014-12-01. I was wondering if you had any
ideas of what could be causing this before I try again.

4) Once I get a working system I'm interested in getting systemd

I'm also very interested in getting java working. There recently has
been some work upstream in openjdk fixing linux/sparc support and as
a result IcedTea 2.5.5 compiles and runs for me on debian/sparc. Because
of this I'm certain we could put together a working ebuild for gentoo.

David Mattli

BRM | 14 Nov 13:31 2012

Re: Sparc Hey

check this out
Jim Faulkner | 2 Sep 03:31 2011

install-sparc64-minimal-20110829 init stops when setting system clock

I'm trying to get my Sun Blade 100 going w/ install-sparc64-minimal-20110829.iso
but the init system gets stuck at "Setting the system clock using the
hardware clock [UTC]".

That's not to say the system locks up:  I can type characters and they
show up on the screen, but init doesn't let me proceed past the setting
system clock script.  The machine is definitely still working.  I've
waited 10 or 15 minutes but init won't give up on the "Setting the
system clock" script.

Actually I can ctrl-c out of it the first time init tries to start the
script, before runlevel 3.  But as soon as it enters runlevel 3 it tries
to start the system clock script again and I'm unable to ctrl-c out of

I see in my kernel messages before modules are loaded that the kernel
successfully sets the system clock from the hardware clock:  apparently
install-sparc64-minimal-20110829.iso's kernel has CONFIG_RTC_HCTOSYS
set.  On my x86 systems /etc/conf.d/hwclock tells me "You do not need
this if you are running a modern kernel with CONFIG_RTC_HCTOSYS set to
y."  Should setting the system clock from the hardware clock be enabled
on the installcd at all?

Alex Buell | 12 Nov 22:45 2010

Linux/SPARC64 Hardware Compatibility List

Four years ago I sent in an email with my box's details. This time I
have two new boxes; 

Model - Ultra 60
Kernel - 2.6.34-gentoo-r11
Stability - Excellent
OBP - 3.31
Net - Yes (HME)
Sound - Yes (CS4321)
Framebuffer - sunffb
Submitter - alexbuell
Comments - Dual 360MHz processors, 2GB RAM, 2 x 36GB SCSI SCA disks.
Console and X11 working well. Minor problems with GNOME/Firefox need

Model - Sun Blade 2000
Kernel - 2.6.34-gentoo-r12
Stability - Excellent
OBP - 4.16.4
Sound - Yes (can't remember which chipset)
Framebuffer - xvr500 
Submitter - alexbuell
Comments - Dual 1.2GHz processors, 4GB RAM, 2 x 73GB FC-AL disks.
Console working well, need X11 fbdev although display looks corrupted,
X11 still works fine. As above, minor problems with GNOME/Firefox needs
sorting although I intend to help fix those problems.


Tactical Nuclear Kittens