From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Phil Blundell <philb@gnu.org>
Cc: openembedded-devel@lists.openembedded.org
Subject: ping**2 [was: Re: [PATCH 2/2] busybox: configure according to {MACHINE, DISTRO}_FEATURES]
Date: Mon, 28 Jun 2010 20:23:59 +0200 [thread overview]
Message-ID: <20100628182359.GD1184@mx.loc> (raw)
In-Reply-To: <20100622203953.GB1184@mx.loc>
On Tue, Jun 22, 2010 at 10:39:53PM +0200, Bernhard Reutner-Fischer wrote:
>On Fri, Jun 11, 2010 at 01:59:12PM +0100, Phil Blundell wrote:
>>On Thu, 2010-06-10 at 23:20 +0200, Bernhard Reutner-Fischer wrote:
>>> If the machine does not provide a choice to use or not use the MMU then
>>> it makes no sense to take that into account for the package arch (think
>>> bfin or i586 or certain coldfires/m68k), yes. If, OTOH, a machine
>>> supports it (let's say ppc) then there must at least be a nice way to
>>> distinguish ppc<endian><mmu><floatingpoint> i would have hoped.
>>
>>Endianness and FPU are clearly both part of the general ABI: virtually
>>every package which contains compiled code is going to have a dependency
>>on those two settings. So, for DISTROs which support multiple values
>>for either of those options, I would expect them to simply be encoded
>>into the default PACKAGE_ARCH (either directly or via TARGET_ARCH); this
>>is indeed what's already done with bi-endian ARM for example. For
>>DISTROs which only support one or the other, there's no need to draw the
>>distinction.
>
>ok, i see.
>>
>>MMU is perhaps a little more complicated since, at least in theory, one
>>could imagine a DISTRO which supported both MMU-equipped and non-MMU
>>hardware and where the majority of binaries were capable of running on
>>both targets. So in that case there might be a legitimate argument for
>>making it be a per-package setting in order to get parallel builds of
>>those packages that do actually care. But I think the time to worry
>>about that would be when the situation does actually arise in practice.
>
>fair enough
>
>I hereby mass-ping the patches in this thread:
>[PATCH 1/3] uClibc: redo configuration
>{2/3 was already applied by khem, thanks!}
>[PATCH 3/3] busybox: picking IPv6 per default is not up to the package
>[PATCH 1/2] uclibc: handle DISTRO_FEATURE="largefile"
>[PATCH 2/2] busybox: configure according to {MACHINE,DISTRO}_FEATURES
ping**2
next prev parent reply other threads:[~2010-06-28 18:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-21 15:31 [PATCH] uClibc: rename main include Bernhard Reutner-Fischer
2010-02-22 5:54 ` Khem Raj
2010-03-12 17:46 ` [RFC, PATCH 0/3] uClibc recipe touchup Bernhard Reutner-Fischer
2010-03-12 17:46 ` [PATCH 1/3] uClibc: rename include file of old releases Bernhard Reutner-Fischer
2010-03-12 17:46 ` [PATCH 2/3] sane-toolchain: add PREFERRED_UCLIBC_VERSION Bernhard Reutner-Fischer
2010-04-05 19:49 ` Roman I Khimov
2010-04-08 9:30 ` Stefan Schmidt
2010-06-09 17:11 ` Bernhard Reutner-Fischer
2010-03-12 17:46 ` [PATCH 3/3] uClibc: redo configuration Bernhard Reutner-Fischer
2010-04-05 20:22 ` Roman I Khimov
2010-06-09 17:10 ` [PATCH 0/3] uClibc configury touchup; RFC WRT feature/dep picking heuristics Bernhard Reutner-Fischer
2010-06-09 21:26 ` RFC " Bernhard Reutner-Fischer
2010-06-09 17:10 ` [PATCH 1/3] uClibc: redo configuration Bernhard Reutner-Fischer
2010-06-09 17:10 ` [PATCH 2/3] uclibc_git: keep PV at "git" Bernhard Reutner-Fischer
2010-06-09 17:10 ` [PATCH 3/3] busybox: picking IPv6 per default is not up to the package Bernhard Reutner-Fischer
2010-06-09 18:44 ` Phil Blundell
2010-06-09 18:52 ` Bernhard Reutner-Fischer
2010-06-09 19:18 ` Phil Blundell
2010-06-09 19:32 ` Bernhard Reutner-Fischer
2010-06-09 20:22 ` Phil Blundell
2010-06-10 19:46 ` [PATCH 1/2] uclibc: handle DISTRO_FEATURE="largefile" Bernhard Reutner-Fischer
2010-06-10 19:46 ` [PATCH 2/2] busybox: configure according to {MACHINE, DISTRO}_FEATURES Bernhard Reutner-Fischer
2010-06-10 19:55 ` Chris Larson
2010-06-10 20:22 ` Phil Blundell
2010-06-10 20:27 ` Chris Larson
2010-06-10 20:50 ` Bernhard Reutner-Fischer
2010-06-10 21:06 ` Phil Blundell
2010-06-10 21:20 ` Bernhard Reutner-Fischer
2010-06-11 12:59 ` Phil Blundell
2010-06-22 20:39 ` Bernhard Reutner-Fischer
2010-06-28 18:23 ` Bernhard Reutner-Fischer [this message]
2010-06-10 22:56 ` Khem Raj
2010-06-11 7:16 ` Bernhard Reutner-Fischer
2010-06-10 20:44 ` Bernhard Reutner-Fischer
2010-06-10 21:09 ` Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100628182359.GD1184@mx.loc \
--to=rep.dot.nop@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=philb@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.