Hello! GCC-4 for SH-4/SH-4a needs multilib support to be able to compile a kernel. The default sh4-linux cross compiler produced by crossdev only supports the '-m4' architecture flag; to build a kernel, '-m4-nofpu' must additionally be supported (same for sh-4a). GCC-3 supports all by default. It need not be anything fancy, simply passing '--enable-multilib --with-multilib-list=m4,m4-nofpu,m4-single,m4a,m4a-nofpu,m4a-single' to the configure script is enough. Thanks!
i thought the gcc-4 peeps were doing retarded stuff with SH ... so if you wanted a nofpu compiler, you had to build for like a sh4_nofpu-linux-gnu target
well, if you crossdev with '-t sh' then you get a compiler which supports all those architectures, but then glibc does not build :) All I want is a GCC-4 which can build kernels (never mind that gcc-4 currently creates unbootable kernels), and possibly a gcc-4 that runs on SH-4 (to build qt4-embedded and ultimately opie) and for that at a minumum m4 and m4-nofpu support is required.
i was gonna say, i'm pretty sure it's been a while since gcc-4 produced bootable kernels on sh :) i use 3.4.6 still with most stuff
i dont like the notion of hard coding target values into the eclass ... anyway we could pull a list of those targets dynamically at buildtime ?
How about an envvar MULTILIB_LIST, which gets evaluated by the ebuild/whatever. Crossdev can set it in response to the '-t ' parameter. For '-t sh4' it should set it to "m4,m4-nofpu,.." and for '-t sh4a' to "m4a,m4a-nofpu,..." If someone wants to emerge gcc-4 for CHOST=CTARGET=sh4, then he/she can set additional archs in MULTILIB_LIST prior to emerge. (there was once a multilib USE flag, no?)
there still is a multilib USE flag ... but what i meant was to have the toolchain.eclass do something like: if use sh && use multilib ; then myconf="${myconf} --enable-multilib" myconf="${myconf} --with-multilib=$(grep out all valid targets)" fi
I have no other idea than the one I wrote down in comment #5. Maybe print a big warning in the gcc ebuild if tc-arch==sh that the "standard" ebuild only produces a compiler suitable for userspace and if you want to build a kernel (or for a special version of SH chips like the sh4-dsp, sh3e, etc), you have to specify the supported target archs in an environment variable (maybe with a link to http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/SH-Options.html#SH-Options )
maybe something like: if [[ ${CTARGET} == sh* ]] && use multilib ; then local sh_multilib=$(sed \ -n '/^[[:space:]]*\*) sh_multilibs=/{s:.*=\([^[:space:]]*\).*;;:\1:;p}' \ config.gcc) myconf="${myconf} --enable-multilib" myconf="${myconf} --with-multilib=${sh_multilib}" fi that gives me: m1,m2,m2e,m4,m4-single,m4-single-only,m2a,m2a-single but still the nofpu target is missing ... what a pain ... it may be easier to write out a list in toolchain.eclass :/
Hm, would it be easier to convince the gcc folks to automatically build a multilib enabled gcc (like gcc-3)?
*** Bug 145850 has been marked as a duplicate of this bug. ***
Created attachment 96366 [details, diff] Crude hack to add multilib support to SuperH-GCC4 compilers Here's a crude hack I use to create multilib-enabled GCC-4 for SuperH targets. It seems to DTRT wrt. e.g. sh4_nofpu-* and gcc-3.
i chatted with some sh guys and i think it might be better to just change the config.gcc file to always do multilib with gcc-4.x the way gcc-3.x did it ... it adds very little buildtime/runtime overhead for this after all, a raw sh4 target cant even build a kernel ;x
Created attachment 96935 [details, diff] gcc4-sh-multilib.patch try this please
Thank you! Works just like GCC-3 now. (and compiled kernels still don't boot ;) )
only thing i can think of before i add this ... with this patch, the default multilib for sh[1234] is all the sh[1234] targets ... would it be better to have the default multilib be all the sh targets for the specified cpu ? so default sh1 would be all the sh1 variants ... default sh2 would be all the sh2 variants, etc... what do you think ?
I say don't bother. What would be gained by that? libgcc size isn't that big a deal (at least for me). I hope someone else can comment on that too.
i was on the fence one way or the other ive committed the proposed patch here and it'll be in 4.1.1-r2 ... thanks for testing
