Bugzilla Bug 24631

I'm trying to compile kernel 2.6.0, but it complains that I have an old
compiler (because I egcs64 installed so that I can compile "old" kernels).

I've checked on arch/sparc64/Makefile to see how it detects my old compiler and
I see that on one place it tries to use gcc or sparc64-linux-gcc (witch is a
link to the egcs compiler). The way it makes that choice, is by executing "gcc
-m64 -S -o /dev/null -xc /dev/null" to see if gcc has support for building 64
bits binaries, and here is my complain :).

Other distributions (e.g. debian unstable) have had several gcc version for the
sparc64 arquitecture with 64 bit compiling enabled. Could this be added to
gentoo's gcc?

*** Bug 24664 has been marked as a duplicate of this bug. ***

*** Bug 24666 has been marked as a duplicate of this bug. ***

I have same problem, I need 2.6 kernel, because cmsg is broken in 2.4's
networking on 64bit. I tried to compile gcc 3.4 from CVS, but gcc failed to
compile because there are no 64-bit libraries in gentoo/sparc64.

One can't run many applications, for example bind DNS server.

GCC 3.4 is not recomended (AFAIK) for kernel compiling. Try 3.2.3 or 3.3.1
instead.

BTW, are you shure you cannot run a bind server on linux sparc? I have a couple
of binds running on E250s running Debian and Splack.

Also, some of bind's ebuilds have "sparc" on there keywords, so it meens that
some sparc developers tested it and it worked. Could you write a bug report
about it, and let me know its number?

I am just trying to compile 64-bit 3.2.3 using emerge. I had to change CHOST
from sparc-unknown-linux-gnu to sparc64-unknown-linux-gnu. I am trying to
recompile everything to 64-bit.

Bind uses control messages with sendmsg() to specify source address of UDP
datagram. This doesn't work properly on sparc64 on 2.4.

I reported it to netdev and got the following response from David S. Miller:

---
> while trying to setup IPv6-capable bind DNS server on UltraSparc II box,
> i have found the following problem:

Yes, this is an unfortunate consequence of how we emulate
socket CMSGs in 32-bit applications running on a 64-bit
kernel in 2.4.x

It is not easily fixable in 2.4.x, in fact it would be such
an intrusive and bug-prone change that I'm probably not going
to fix it in 2.4.x

The workaround in the app is the use slightly larger than
necessary CMSG buffers.  Sorry :(

2.5.x/2.6.x does things properly and the bug shouldn't show up
there.
---

You'll need to build a sparc64 cross-compiler in order to build kernels.  I
haven't gotten this to work well on a sparc system itself, so keep an x86 box
handy.  For a mere kernel cross-compiler, you only need a cross-binutils and a
cross-gcc that only compiles C code.  C++, F77, ADA and others aren't needed. 
Going beyond the kernel into a 64-bit glibc is uncharted territory, and more or
less a lonely adventure at the moment.

Anyways, grab an x86 box, and try these compile settings:

export myARCH=sparc64-unknown-linux-gnu
export myHOST=i686-unknown-linux-gnu
export myDEST=/home/crossdev/sparc64

--- binutils ---
../configure --target=${myARCH} --host=${myHOST} --prefix=${myDEST}
--enable-shared --enable-64-bit-bfd && make


--- headers ---
cd ${myDEST}
cp -r /usr/include/* ${myDEST}/include/
rm -Rf ${myDEST}/include/linux
rm -Rf ${myDEST}/include/asm*
cp -r /usr/src/linux/include/linux ${myDEST}/include
cp -r /usr/src/linux/include/asm-$(echo ${myARCH} | cut -d- -f1)
${myDEST}/include
cp -r /usr/src/linux/include/asm-generic ${myDEST}/include
ln -s ${myDEST}/include/asm-$(echo ${myARCH} | cut -d- -f1)
${myDEST}/include/asm


--- gcc-bootstrap ---
../configure --prefix=${myDEST} --host=${myHOST} --target=${myARCH}
--with-newlib --disable-shared --disable-threads --enable-languages=c
--disable-multilib --without-headers && make


Those command can literaly be pasted right in.  They first set some bash
variables (feel free to change the install location), compile binutils, then
copies some headers from /usr/include and /usr/src/linux/include to the right
spot in the install location, and then builds gcc for a C-compiler only.  

AFTER building Binutils, make SURE to add the bin path (i.e.,
/home/crossdev/sparc64/bin) to your PATH, otherwise gcc will fail.

Provided gcc compiles and installs correctly, you can then try building a
sparc64 2.5/2.6 kernel.  I have used to successfully compile a 2.5.70 kernel,
but I have not tested the kernel on my sparc64 machine yet.  Gonna wait for the
real 2.6 kernels to be released before hand.

Whoops, one minor error, Change:

export myHOST=i686-unknown-linux-gnu

to

export myHOST=i686-pc-linux-gnu


Also, the best way to get source code for gcc/binutils is to use the "ebuild" command to "unpack" the gcc-3.2.3 or 3.3 source and binutils source, then copy the source tree from your portage TMPDIR.

(Re to post#5)

Wow. _Very_ interesting. Does it affect ipv6 dns servers only? In that case, can you file a bug about it assigned to the sparc porters so that they modify the ebuild so that it won't allow sparc64 *and* ipv6 in the USE vars.

Created an attachment (id=15976) [details]
experimental ebuilds for gcc64 and binutils64

you have to untar the tar in the dir above your portage or PORTAGE_OVERLAY dir.
and you have to emerge them manually or user KEYWORD=~sparc. Everything
installs in /opt/sparc64 so before compiling the kernel you have to do "export
PATH=/opt/sparc64/bin:$PATH". To be sure you are not using the ecgs64 you can
(not a must) unmerge egcs64.

Linux xxxx 2.6.0-test2 #1 SMP Mon Jul 28 13:25:57 CEST 2003 sparc64 sun4u TI
UltraSparc II (BlackBird) GNU/Linux
# uptime
16:19:15 up 15 days, 35 min, 2 users, load average: 1.82, 2.72, 2.00


happy compiling

Created an attachment (id=15977) [details]
experimental ebuilds for gcc64 and binutils64

you have to untar the tar in the dir above your portage or PORTAGE_OVERLAY dir.
and you have to emerge them manually or user KEYWORD=~sparc. Everything
installs in /opt/sparc64 so before compiling the kernel you have to do "export
PATH=/opt/sparc64/bin:$PATH". To be sure you are not using the ecgs64 you can
(not a must) unmerge egcs64.

Linux xxxx 2.6.0-test2 #1 SMP Mon Jul 28 13:25:57 CEST 2003 sparc64 sun4u TI
UltraSparc II (BlackBird) GNU/Linux
# uptime
16:19:15 up 15 days, 35 min, 2 users, load average: 1.82, 2.72, 2.00


happy compiling

Thanks for the ebuilds. They both work like a charm, and I'd like to offer them
as a workarround to users while I kill this bug.

BTW, the binutils-sparc64 package isn't needed as the current binutils package
supports working with 64 bit binaries.

Created an attachment (id=16058) [details]
updated ebuilds

added to 2 ebuilds, binutils-sparc64-2.14.90.0.5 and gcc-sparc64-3.3.1, same
rules apply as the old ones

xming

A little follow up here. I have a binutils ebuild that make the apropriate
links for the sparc64 arch were needed. Please test it arround and let me know
if it works ok. It's available at
http://dev.gentoo.org/~fede2/binutils-2.14.90.0.5-r2.ebuild

As for the gcc ebuild, the ebuilds of versions 3.2.3 and 3.3.1 should be
modified to add a new local use flag called "sparc64" and the following:

      use sparc64 && (
              einfo "Turning up 64 bit support"
              CCHOST=sparc64-unknown-linux-gnu
              CHOST=sparc64-unknown-linux-gnu
      )

I think this is more than enough to make it work, but not only I don't have the
man/cpu time to work with this bug anymore, but also, I'm not confided enough
about making my firts change to an ebuild, on such an important ebuild.

To whoever will follow with this bug, I recomment to build a stage3 with the 64
bit enabled compiler as a way to check that nothing got broked.

I'm not sure if this sparc64 local USE flag would be enough.  Since with
binutils and gcc, you're essentially building a cross-compiler because we have
a 32-bit userland and are trying to achieve a 64-bit kernel cross-compiler. 
Thus, binutils and gcc will need separate packages for 64-bit, because the main
binutils will wind up being configured for 32-bit only.  I don't think it is
possible to build a 32 and 64-bit aware binutils, but don't quote me on that.

http://dev.gentoo.org/~kumba/misc/64bitkerneltools.tar.bz2

That's a set of gcc-3.3.1 and binutils-2.14.90.0.5 ebuilds based off xming's
work.  I dropped gcc-3.2.3, as 3.3 has better 64-bit support last I heard, and
by the time these ever become stable, 3.3.1 will probably be the mainline
compiler.  They'll build either sparc64 or mips64 kernel compilers, which is
really all that's needed.  I have tested the mips64 compiler, which built a
half-booting kernel (don't ask, I didn't expect it to boot period), and since
the sparc64 and mips64 builds are virtually the same (diff them), the sparc64
compiler should work just as well.

Noup. the current binutils _does_ support 64 bit binaries. If you check the
binutils ebuild I posted for testing, the only diff (IIRC... I have a short
memory) is to make the apropriate links.

And the guys from debian have a 64/32 bit compiler by default. Dunno about
other distros; but I do plan to do it for splack when I get to it.

Looking into this now.  Would like to get 64 bit gcc-3.x into the tree for
kernels soon.

Created an attachment (id=18812) [details]
binutils with both 32bit and 64bit setups

Attached a version of the binutils-2.14.90.0.6-r3.ebuild file that includes
the support/setup for 64 bit programs as well.  This is based off the work
fede2 did, but updated for the latest package version.  I built `kumba's
gcc-sparc64 against it and sucessfully compiled and booted a 2.4.22 kernel
on a Blade 100 with this arrangement.

Created an attachment (id=20122) [details]
binutils-CHOST64.patch

Hi guys, this should be generic for both mips64 and sparc64 .. look ok ?

Azarah,

Looks good and works for for sparc64.

Thanks :)

Commited for later binutils ebuilds.