In order to handle gcc-4.x stage1 & 2 C/C++ cross-compile builds on a PXA270 to support IWMMXT etc. the attached patch modifies toolchain.eclass. It adds the following optional command line variable CFLAGS_FOR_TARGET, as BOOT_CFLAGS does not seem to propagate nor be used appropriately in Canadian compiler / library builds (in my case setting it to -mcpu=iwmmxt -mabi=aapcs-linux -mfloat-abi=soft -mfpu=vfp etc.). The patch also handles the problem of overly long EXTRA_ECONF passed to configuration (in my case --enable-cxx-flags='-mcpu=iwmmxt etc.') which seem to be truncated, by building a temporary file build/xtraconfig to execute (not the best of ideas, but it works ... still trying to figure out where the sub-shell execution command line size is set). Nothing earth shattering, but it's a simple generic enhancement that other gentoo-embedded folks may be able to use to their advantage. Reproducible: Always --- toolchain.eclass.orig 2008-02-17 20:40:07.000000000 -0500 +++ toolchain.eclass 2008-02-19 13:51:55.000000000 -0500 @@ -1314,7 +1314,8 @@ # for statically linked apps but not dynamic # so use setjmp/longjmp exceptions by default if [[ ${CTARGET} == *-uclibc* ]] ; then - confgcc="${confgcc} --disable-__cxa_atexit --enable-target-optspace" + EXTRA_ECONF=${EXTRA_ECONF-"--enable-target-optspace"} + confgcc="${confgcc} --disable-__cxa_atexit" [[ ${GCCMAJOR}.${GCCMINOR} == 3.3 ]] && \ confgcc="${confgcc} --enable-sjlj-exceptions" elif [[ ${CTARGET} == *-gnu* ]] ; then @@ -1343,7 +1344,10 @@ # and now to do the actual configuration addwrite /dev/zero - "${S}"/configure ${confgcc} $@ ${EXTRA_ECONF} \ + # create file due to long EXTRA_ECONF + echo "${S}/configure ${confgcc} $@ ${EXTRA_ECONF}" > "${WORKDIR}"/build/xtraconfig + chmod 0755 "${WORKDIR}"/build/xtraconfig + "${WORKDIR}"/build/xtraconfig \ || die "failed to run configure" # return to whatever directory we were in before @@ -1408,10 +1412,12 @@ fi if is_crosscompile; then + # use CFLAGS_FOR_TARGET crosscompile libgcc + CFLAGS_FOR_TARGET=${CFLAGS_FOR_TARGET-"-O2"} # In 3.4, BOOT_CFLAGS is never used on a crosscompile... # but I'll leave this in anyways as someone might have had # some reason for putting it in here... --eradicator - BOOT_CFLAGS=${BOOT_CFLAGS-"-O2"} +# BOOT_CFLAGS=${BOOT_CFLAGS-"-O2"} else # we only want to use the system's CFLAGS if not building a # cross-compiler. @@ -1419,13 +1425,14 @@ fi pushd "${WORKDIR}"/build - einfo "Running make LDFLAGS=\"${LDFLAGS}\" STAGE1_CFLAGS=\"${STAGE1_CFLAGS}\" LIBPATH=\"${LIBPATH}\" BOOT_CFLAGS=\"${BOOT_CFLAGS}\" ${GCC_MAKE_TARGET}" + einfo "Running make LDFLAGS=\"${LDFLAGS}\" STAGE1_CFLAGS=\"${STAGE1_CFLAGS}\" LIBPATH=\"${LIBPATH}\" BOOT_CFLAGS=\"${BOOT_CFLAGS}\" CFLAGS_FOR_TARGET=\"${CFLAGS_FOR_TARGET}\" ${GCC_MAKE_TARGET}" emake \ LDFLAGS="${LDFLAGS}" \ STAGE1_CFLAGS="${STAGE1_CFLAGS}" \ LIBPATH="${LIBPATH}" \ BOOT_CFLAGS="${BOOT_CFLAGS}" \ + CFLAGS_FOR_TARGET="${CFLAGS_FOR_TARGET}" \ ${GCC_MAKE_TARGET} \ || die "emake failed with ${GCC_MAKE_TARGET}"
post patches as attachments, not inline ... bugzilla mungs them the 1st hunk is wrong ... EXTRA_ECONF is for users to inject arbitrary flags, not default values the 2nd hunk looks unrelated and broken the 3rd/4th have to do with CFLAGS_FOR_TARGET ... if the gcc build system isnt setting those up properly, you should fix that instead of ignoring the issue by forcing it via make. i also think the gcc build system adds custom flags to the variable which you dont want to go ignoring.
I agree, but the create "bug" process seems to have no place to attach files (such as patches), such as the nice 'Create ... Attachment' feature above. Hence my placing in (unfortunately) inline. Hunk #1: agreed EXTRA_ECONF is simply to inject arbitrary flags, however forcing the libraries to be optimized for space for all users is not necessarily a great idea. If a user does nothing the default remains, however if the user so wishes they can override it as well as any other per the option. Perhaps using the flag minimal for the space optimization would be another approach but would break the formerly used default. Hunk #2: unfortunately I do not understand what the terse response of unrelated and broken means. If what you mean is what I stated earlier it is necessary due to ebuild seeming to truncate commands at approximately the ~1030 characters mark (executing the exact same command from bash works, as xargs shows a limit of 32768), I agree something is broken. It is only related by the fact that it is needed for a EXTRA_ECONF of only a few flags given the size of the confgcc (such that if you add a little more to confgcc, it too will run into the same strange limit). There seems to be no method of overriding this behavior, and so the perhaps old fashioned approach of writing it to a file and then executing the file. Hunk #3/4: as I understand it, the CFLAGS_FOR_TARGET is explicitly setup for users optimization for cross compilers (and not BOOT_CFLAGS as noted in the base ebuild) hence the suggestion for inclusion to set it. GCC's default is '-O2', and therefore the patch does the same. The result is the same if left untouched by the user, but would allow users to better customize library compilation (a problem met by many embedded programmers, particularly in the ARM family). All of these are simply minimal enhancements which have allowed me to create a better uclibc for my targets. In the spirit of open source, I offer them to the community for others to enjoy or not. Have fun!
(In reply to comment #2) > I agree, but the create "bug" process seems to have no place to attach files > (such as patches), such as the nice 'Create ... Attachment' feature above. > Hence my placing in (unfortunately) inline. Once you commit a bug you can create an attachment to the bug. > Hunk #1: agreed EXTRA_ECONF is simply to inject arbitrary flags, however > forcing the libraries to be optimized for space for all users is not > necessarily a great idea. If a user does nothing the default remains, however > if the user so wishes they can override it as well as any other per the option. > Perhaps using the flag minimal for the space optimization would be another > approach but would break the formerly used default. I think that is an unrelated feature request, bugzilla works better for an issue a time. > > Hunk #2: unfortunately I do not understand what the terse response of unrelated > and broken means. If what you mean is what I stated earlier it is necessary due > to ebuild seeming to truncate commands at approximately the ~1030 characters > mark (executing the exact same command from bash works, as xargs shows a limit > of 32768), I agree something is broken. It is only related by the fact that it > is needed for a EXTRA_ECONF of only a few flags given the size of the confgcc > (such that if you add a little more to confgcc, it too will run into the same > strange limit). There seems to be no method of overriding this behavior, and so > the perhaps old fashioned approach of writing it to a file and then executing > the file. The approach tries to fix a problem by workarounding it, I think would be better split this part to another bug as well.
i dont really care about the defaults, we can change them. simply dropping the configure flag from the eclass sounds fine to me. anyone who wants it can add it themselves. tying it USE=minimal is a possibility, but dropping it sounds better. if there is an arg problem, we diagnosis that by itself. simply making the change in an unrelated bug without explanation is not the way to go about things. if you look at the build system, you'll see more things than just "-O2 -g" get set in CFLAGS_FOR_TARGET ... that is why we cant just go tromping on it. if you describe exactly what it is you're trying to accomplish, we can investigate how to do that. i dont think CFLAGS_FOR_TARGET is the answer.
I'm sorry if I confounded the system by combining what I mistakenly saw as a single simple enhancement. If you wish I will resubmit these as separate patches (hopefully entered correctly now that I understand how this Bugzilla has been configured). I endeavor to be very cautious when changing defaults in base functionality such as core tools, hence the setting of a default in what normally is never touched by most ebuilds. If you believe that this will not affect the end users, then dropping the space flag would clean this up for me (without resorting to setting countermanding flags in ECONF). Hopefully the truncation is simply an argument problem, and perhaps (if I had more time) I could delve into the portage system to see if there is just a default that could be gigged a little. But I hate to tread on too many toes in what has been a stellar system to work with. Actually from the very careful delving into what was propagated from the configure / Makefiles from the root to each of the sub directories (for my case), is precisely why I choose to modify CFLAGS_FOR_TARGET. It was also from this that I gleaned the '-O2' which you correctly note that should be '-O2 -g' (very rarely has the debug information been useful to me, and so I did not include it in the patch ... my bad). I certainly would love to know of another that might be used for building the gcc cross compiler and the associated libraries so consistently. The crux of the issue, in my case, is the ARM standard(s) of which there are many from Advanced RISC Machines or their licensees like Intel (largely depending on the architecture, published ABIs, or OSS interpretations). It is these issues which range from the eternal big vs. little endian question, to which architecture variant (instruction set, cores built in, even including proprietary extensions), to the very standard of how thou shalt pass pseudo-floating point registers on the integer pipeline that vex me. And of course, as the tools endeavor to keep up in these constantly shifting grounds, that inconsistencies have occurred in the handing of defaults between each of the tool groups (to no surprise). Currently binutils sets one standard as default, gcc seems to default to the slightly more advanced set, but uclibc does not. This is certainly not to say that they cannot be set the same (which is the point of these patches scattered about the various groups), but that they must be tuned (each in there own way). The effect is so that they may harmonize in the most efficient manner (ever the difficulty of the embedded programmer with the paucity of computing power, memory, etc.). So for example in the PXA270 target I have in front of me, for gcc (for building the base C libraries) I must pass the the make (amongst the other defaults which are consistent): -mcpu=iwmmxt -mabi=aapcs-linux -mfloat-abi=soft -mfpu=vfp but for binutils (subtly similar): -mcpu=iwmmxt -meabi=4 -mapcs-reentrant -mfloat-abi=soft -mfpu=softvfp or in gcc parlance (of course): -Wa,-mcpu=iwmmxt,-meabi=4,-mapcs-reentrant,-mfloat-abi=soft,-mfpu=softvfp but to build libstdc++v3 it must be configured with (a rather long flag): --enable-cxx-flags='<all of the above>' in addition to handle a uclibc issue (a historical problem, that I resolved yesterday): -Wl,--accept-unknown-input-arch Bleah! I could have simply hard coded this as a patch to the default configurations, or similarly used the ebuild directory to override (which unfortunately would become stultified as the versions moved on). Instead by adding to the ebuild a simple generic method of extension, the same issues "could" be solved for all architectures and users (should they so choose). I hope that, given your experience in the Gentoo community, you may be able to suggest a less intrusive method of being forced to "rice" these tools in order to begin the even more demanding task ahead.
Any further thoughts / suggestions for a better ebuild (given the issues)?
Reading this over I have no idea where we are at with this bug. Does anyone need any of the enhancements described here still?
The minor fixes described here are still necessary to solve the issues if one wishes to build embeddable versions of Gentoo (and hence a cross compiler and associated tools/libraries optimized for the architecture). As this will probably never be the case given the capabilities of OpenEmbedded, you can close this (as well as http://bugs.gentoo.org/show_bug.cgi?id=230365) as wontfix. Thanks for following up on this, and good luck bug hunting!
