@toolchain: what we do?
For me, there seems to be a new "feature" with vanilla-sources-2.6.25_rcx which forces
make CROSS_COMPILE="/usr/bin/sparc64-unknown-linux-gnu-" ...
Ferris: there's no need to specify the full path
i dont really track sparc so i dont really know what the exact background is here, so i'm guessing ...
for the most common sparc case:
- userland is 32bit
- kernel is 64bit
- linux-2.6.25+ will not build with a 32bit toolchain anymore
- sparc systems require kgcc64 ebuild
- anyone building a sparc 64bit kernel needs to do (just like on mips) `make CROSS_COMPILE=sparc64-unknown-linux-gnu-`
that summary OK ?
or you guys/LKML could investigate changing the sparc makefile like so (obviously this is a hand typed example; expand for your needs):
-KBUILD_CFLAGS += -msome-magic-flag
+KBUILD_CFLAGS += $(call cc-option,-msome-magic-flag)
this assumes that your active `gcc` toolchain will of course be able to compile the kernel normally ...
Probably correct. I just happened to notice that the makefile could no longer find the cross compiler. So far as I know, the kernel would never build in 32-bit mode.
so the older kernels would automatically default to some sparc64-...- prefix ?
in other words, how is it working today for people ?
Some more info:
^^ This is the commit that broke it.
Regarding what you proposed, Mike, it already does that as of this commit:
You may be interested in what sparc kernel maintainer said here: http://marc.info/?l=linux-sparc&m=120640230127788&w=2
It worked for me until I did a rev bump to vanilla-sources-2.6.26_rc6 to see if I could find a kernel anywhere beyond 2.6.19 which did not panic at boot time. And, in fact:
Linux polylepis 2.6.25-rc6 #3 SMP Tue Mar 25 19:29:22 UTC 2008 sparc64 sun4u TI UltraSparc III (Cheetah) GNU/Linux
(In reply to comment #5)
> Some more info:
> ^^ This is the commit that broke it.
> Regarding what you proposed, Mike, it already does that as of this commit:
> You may be interested in what sparc kernel maintainer said here:
Actually, I agree that there is no reason at all not to let normal gcc accept '-m64' etc.
wrt the default sparc compiler supporting sparc64, that's really been up to the sparc team to maintain ... we've really only changed sparc related stuff as the sparc guys ask
i dont recall ever digging deeply into sparc internals, so you guys will have to make some suggestions
debian is about the only other sparc distribution worth a damn that i know of
Created attachment 147314 [details]
This is what debian does, looks easy, doesn't it?
looks like when the sparc maintainer said "get out of the stone age", they actually meant "apply a bunch of changes which arent in upstream"
could you drop an e-mail to the firstname.lastname@example.org mailing list on the topic asking for more info ? you dont need to subscribe to post ...
thanks ... btw, you only need to specify the full path in CROSS_COMPILE only when the binary isnt in your PATH
(In reply to comment #12)
> btw, you only need to specify the full path in CROSS_COMPILE only
> when the binary isnt in your PATH
I know, i just copied it from fmccor's post and didn't notice :)
Created attachment 150174 [details]
No answer so far.
I was googling for some info, and noticed that debian has the two compilers as well. However they seem to use a wrapper for using the 32bits or the 64 bits one. I'm attaching the wrapper included in the gcc package(gcc-defaults).
well that makes the guys' response on lkml even more stupid
So...what we do? Still no answer, what do you think about implementing something like attachment 150174 [details]?
> looks like when the sparc maintainer said "get out of the stone age", they
> actually meant "apply a bunch of changes which arent in upstream"
they are in upstream now, he commited them 8 days ago:
this means with gcc 4.3.1 all we need to do to get a sparc-unknown-linux-gnu- that can do -m64 and defaults to -m32 is:
configure --host=sparc-unknown-linux-gnu --enable--targets=all
> I was googling for some info, and noticed that debian has the two compilers as
> well. However they seem to use a wrapper for using the 32bits or the 64 bits
lenny(testing) and sid(unstable) actually use multilib with "lib" for 32bit libs and "lib64" for 64bit libs. exactly what upstream gcc 4.3.1 does(or will do, it's not released afaik)
Created attachment 153367 [details]
patches to create profile 2008/experimental/multilib
I backported the patch to 4.3.0 and wrote some patches to create a multilib profile, looks really good.
In my opinion introducing a multilib profile and introducing a wrapper for non-multilib profiles would be the best action.
*** Bug 245576 has been marked as a duplicate of this bug. ***
sorry for the delay ... added the patch to cvs for 4.3.2-r1
this is the last one i received via e-mail ... assuming it's up to date ...
With revision 1.2 of this patch gcc-4.3.2-r1 doesn't compile on sparc.
I'll attach a full build.log in a few moments.
While revision 1.1 was fine, 1.2 removes the defines for GLIBC_DYNAMIC_LINKER* which don't seem to be in gcc/config/linux.h (at least grep can't find them).
Can you change gcc-4.3.2-patches-1.3.tar.bz2 to include revision 1.1 of the patch?
Created attachment 176437 [details]
yeah, i got a little overzealous, sorry about that
np, thanks for the quick fix, works fine now :)
to all those guys cc'ed:
If you want to try this read http://dev.gentoo.org/~bluebird/sparc-multilib/ but beware: it's experimental. It will still take some time until we announce it as stable on the gentoo-sparc mailing list ;)