On 06/11/2016 04:15 PM, alexmcwhir...@triadic.us wrote:
> "Pulled the plug" as in future releases of the sparc port ceased in it's 
> current form (64bit kernel 32 bit userland).

Well, we didn't pull the plug on Squeeze. We dropped support for 32-bit SPARC 
with a 64-bit kernel in general, mainly
due to lack of maintainers, hardware falling apart and the lack of upstream 
development. Keeping the port alive would
have been dishonest towards our users. It wasn't something we could ship as 
stable after all. So it had to go.

However, at that point the release team already indicated that SPARC support 
could return in the form of "sparc64" which
is what we are currently working on.

> Gentoo would get you kernel ~4.1 IIRC if you track the stable repository 
> flags. That kernel is leagues ahead of kernel 3.2 as far a stability goes. 
> Not to say
> there aren't bugs, because there are quite a few. As well as applications 
> that don't work and various hacks you'll have to make to the package system 
> to get a
> working current version of gcc to build.

Linux 4.1 wasn't out back then when "sparc" was removed from Debian, if I 
remember correctly.

>>> Granted currently it's still a 32 bit userland as my 64 bit userland 
>>> patches have not hit upstream.
>>
>> Would you mind sharing your patches, please? Those might be useful in
>> Debian, too. Which packages
>> did you fix?
>>
> 
> I'll dig through the relevant one on monday, but 90% of the patches are to 
> the Gentoo package system (which is also the build system) to support 
> compiling
> everything 64 bit.
> 
> Off the top of my head...
> 
> Disable gold for udev as it was broken on sparc with gcc 4.8.5 - probably 
> fixed here as gcc is much newer here

Gold wasn't just broken, it was actually never implemented on SPARC until 
recently when upstream added support
for the STT_REGISTER on SPARC, see:

> https://sourceware.org/bugzilla/show_bug.cgi?id=19019

> rework glibc building to determine the right cpu flags, had to do the same 
> for openssl. these two apps need to know the actual cpu you're building for - 
> also
> most likely fixed here

OpenSSL never had issues on sparc64, glibc still has. Jose Marchesi from Oracle 
just recently addressed some issues with
unaligned access in one of the string test.

> patch zfs to work on sparc - detailed in my last message. Will get patches.

I cannot comment on ZFS, I haven't done any ZFS tests on Debian yet.

> enable 64 bit in elftoaout - must be fixed here as silo seems to work ok.

I have done the same in Debian. The Oracle guys hinted me at that problem.

> force silo to build 32 bit. Gentoo has old silo, not sure if that's still 
> relevant with newer silo versions?

silo on sparc64 in Debian is fully 64-bit, also thanks to some support from the 
Oracle people. They have quite
a number of patches in silo but last time I checked, none of these had been 
upstreamed to Dave Miller's
repository on git.kernel.org, unfortunately.

The current patches can be extracted from Oracle's silo package:

> http://yum.oracle.com/repo/linux_sparc64/latest/silo-1.4.14-4.0.18.el6.src.rpm

They are also working on adding SPARC support to GRUB, but I have no idea how 
much that has progressed yet.

> fix google's protobuf, for whatever reason it assumes you're running solaris 
> if you have a sparc cpu...

Yup, that was fixed in Debian, too. The same issue affects the embedded 
protobuf in Firefox and Thunderbird, btw.

However, Firefox/Thunderbird still won't build on sparc64, see:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1275204

> that's all i can think of for now. Like i said, pretty small stuff. Most of 
> the work was getting the packaging system to work.

Ok, so it sounds we actually patched far more in Debian. But I guess that is 
owed to the fact that we actually try to build
all packages in Debian by default. Gentoo provides only a small set of prebuilt 
packages and the user has to build the rest
from source. However, unless you don't a full archive build on a certain 
architecture, you can never be sure that everything
builds fine on a given architecture.

That's why I'm also not a fan of source-based distributions in general. I have 
seen the same problem on sh4 which Gentoo claims
to support. However, before I actually touched sh4 in Debian, the toolchain was 
quite broken and I filed dozens of gcc and
binutils bugs until everything was shaped up that we were finally able to build 
gcc-5 on sh4. That took over half a year.

>>> The unstable debian sparc64 port does support generic 64 bit sparc. My E6K, 
>>> V210, V215, and Netra X1 are all running it. It may be classified as 
>>> unstable, but i
>>> haven't had a crash occur from system instability yet.
>>
>> There have been recently some issues with kernel 4.6.x, but those have
>> already reported upstream
>> to the kernel developers. See the sparclinux LKML list archives for
>> this month. Otherwise, Debian's
>> sparc64 is working with none or minor issues only.
> 
> Yea im keeping track of some of those, luckily i haven't come across any of 
> them myself yet.

Good.

Adrian

-- 
 .''`.  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

Reply via email to