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

Rob Landley rob at landley.net
Thu Feb 10 19:42:01 UTC 2011


I mentioned that my build was dying due to trying to use -mfdpic which
is a target-specific option for the FRV processor:

  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uClibc-mmu.patch
Type: text/x-patch
Size: 5408 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20110210/8e5718d0/attachment.bin>


More information about the uClibc mailing list