http://marc.info/?l=linux-sparc&m=120638895101756 @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: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=54cd6ddec77b75e6926d73d263aec72255b24030 ^^ This is the commit that broke it. Regarding what you proposed, Mike, it already does that as of this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=966d905634de4433cea465fdcea19503c4ae260f 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: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=54cd6ddec77b75e6926d73d263aec72255b24030 > ^^ This is the commit that broke it. > > Regarding what you proposed, Mike, it already does that as of this commit: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=966d905634de4433cea465fdcea19503c4ae260f > > You may be interested in what sparc kernel maintainer said here: > http://marc.info/?l=linux-sparc&m=120640230127788&w=2 > 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] sparc-biarch.dpatch 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 gcc-help@gcc.gnu.org mailing list on the topic asking for more info ? you dont need to subscribe to post ...
http://gcc.gnu.org/ml/gcc-help/2008-04/msg00121.html
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] sparc-gcc.c 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: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00204.html 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 > one. 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.
Thoughts, Mike?
*** 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 ... http://sources.gentoo.org/gentoo/src/patchsets/gcc/4.3.2/gentoo/80_all_sparc-biarch.patch?rev=1.1
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] gcc-4.3.2-r1 build.log
yeah, i got a little overzealous, sorry about that fixed now
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 ;)
