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