Ah, figured out the -mfdpic thing, [PATCH] included.
Rob Landley
rob at landley.net
Sat Feb 12 02:34:22 UTC 2011
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
More information about the uClibc
mailing list