On 02/11/2011 12:55 PM, Bernhard Reutner-Fischer wrote: > On Thu, Feb 10, 2011 at 01:42:01PM -0600, Rob Landley wrote: >> I mentioned that my build was dying due to trying to use -mfdpic which >> is a target-specific option for the FRV processor: > > It's not only for FRV, it's also used on bfin (should be fixed in the > docs).
Right, so when mike changed that in gcc he didn't bother to update the docs, when he changed it in uClibc he didn't bother to put any docs on the config entry... >> http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html >> https://bugs.busybox.net/show_bug.cgi?id=3193 >> >> The problem is that uClibc has an utterly useless user-visible >> "TARGET_HAS_MMU" as well as "TARGET_USE_MMU", and I took the first out >> of miniconfig because I'd complained about the redundant option during >> the dev cycle and thought it was gone. >> >> Here's a patch to remove the redundant option. The only decision the >> end user has to make is "Do I want MMU or NOMMU?", and TARGET_USE_MMU is >> the thing that selects that. (There's even code in the test suite >> making sure nothing in the actual build ever uses ARCH_HAS_MMU, it's >> JUST a dependency guard on the only symbol that actually matters.) >> >> Architectures that have no MMU still set ARCH_HAS_NO_MMU, and that's >> used directly as the visibility guard for TARGET_USE_MMU which is the >> only user visible setting, and which defaults to y just like it always >> did. (The previous code that selected TARGET_HAS_MMU was selecting a >> symbol that defaulted to Y, for no apparent reason. There was a whole >> lotta NOP going on, and I've removed it.) >> >> The fact that when you select a nommu system, it defaults to creating a >> binary format that's only available on the FRV architecture with no hint >> that it's a target-specific format, is a separate bug introduced without >> explanation in commit 14db067a8bdcdc7a25. I'm leaving that for now, in >> hopes somebody either fixes it or writes a help option explaining what >> they were thinking. >> >> Rob > > NAK. Why? > I also think a > prompt "Target File Format" > + default UCLIBC_FORMAT_ELF if ARCH_USE_MMU > + default UCLIBC_FORMAT_FDPIC if !ARCH_USE_MMU && TARGET_frv > + default UCLIBC_FORMAT_SHARED_FLAT if !ARCH_USE_MMU > > is not ideal, please just configure your format properly according to > your needs (throughout your setup). Why do you want to have two user-visible symbols that mean exactly the same thing? (What part of my explanation was incorrect?) Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
