Le 18/04/2014 14:16, Patrick Baggett a écrit :
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 now
SPARCv9 = modern (post 1997) 64-bit CPUs, Linux and GCC supports them
just fine.
And just so we can finally kill this rumor dead:
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/SPARC-Options.html#SPARC-Options
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 ?
Seb
--
To UNSUBSCRIBE, email to [email protected]
<mailto:[email protected]>
with a subject of "unsubscribe". Trouble? Contact
[email protected] <mailto:[email protected]>
Archive: https://lists.debian.org/[email protected]
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 :
> 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
