Le 18/04/2014 14:16, Patrick Baggett a écrit :
Maybe it was poor understanding by my side. I read the https://release.debian.org/jessie/arch_qualify.html and at the bottom line, there is this mention of this :I really don't understand why this "32-bit gone" myth is happening. It was poor wording at least. Debian doesn't even support the ancient 32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running in 32-bit code, it's like x32 ABI in x86 land.
SPARCv7, SPARCv8 = old 32-bit CPUs, Linux kernel barely supports them nowSPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them just fine.
And just so we can finally kill this rumor dead:
GCC still supports the 32-bit ABI:
With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference from the V8 ABI is that the global and out registers are considered 64 bits wide. This is enabled by default on Solaris in 32-bit mode for all SPARC-V9 processors.
So no, you don't need to rebuild everything as 64-bit binaries, or should I say, rebuild under LP64 model. That wouldn't even make sense and would hurt performance. Please refer anyone who believes this to this message.
Patrick
So, if I have understood correctly, the main problem is that 32bit compilation is not supported in the current releases of gcc ?
Going to 64bit userland is a huge leap forward.
For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough.
I have no clue why is it marked oldkernel something related to the buildd ?
SebArchive: [🔎] 5350E5E0.1090901@nerim.net" target="_blank">https://lists.debian.org/[🔎] 5350E5E0.1090901@nerim.net
--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> sparc
> Upstream Support
> According to the gcc maintainer 32bit code generation as we use it is no longer supported upstream and we should aim for > a switch to 64bit userland anytime soon.
This is quite clear, and maybe plain wrong according to you.
This seems to prevent switch from gcc 4.6 to gcc 4.8.
Seb