Ah, figured out the -mfdpic thing, [PATCH] included.

[Mike Frysinger]

On Friday, February 11, 2011 21:34:22 Rob Landley wrote:
> 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...

no idea what you're talking about.  i didnt do the gcc nor uClibc port for 
FDPIC for Blackfin processors.

> >>  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.
> > 
> > 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?)

no, the "has mmu" is there for the kconfig tree to make the the "use mmu" 
available to the user.  the source then keys off of "use mmu".  nowhere does 
the user select "i have a mmu", they only select "i want to use the mmu".  
seems pretty straightforward to me.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20110221/b65fbbb0/attachment.asc>