Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Subject: Re: Can we drop eglibc-utils from LIBC_DEPENDENCIES?
Date: Fri, 16 Dec 2011 18:37:20 -0800	[thread overview]
Message-ID: <4EEC0060.4050808@linux.intel.com> (raw)
In-Reply-To: <1324085367.4568.119.camel@ted>



On 12/16/2011 05:29 PM, Richard Purdie wrote:
> On Fri, 2011-12-16 at 15:34 -0800, Darren Hart wrote:
>>
>> On 12/16/2011 03:20 PM, Darren Hart wrote:
>>>
>>>
>>> On 12/16/2011 01:07 PM, Koen Kooi wrote:
>>>>
>>>> Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven:
>>>>
>>>>> I'm working on a minimal distro definition, and found that eglibc-utils
>>>>> pulls in bash (needed for tzconfig and xtrace apparently)
>>>>
>>>> My first thought is: fix the bashisms in those scripts, I bet ubuntu/fedora/arch/gentoo have patches for that,
>>>
>>>
>>> Agreed, this would be a good thing to do. However, I still shouldn't
>>> need to include this in a "tiny" distribution.
>>>
>>>
>>>>> which pulls in
>>>>> gettext, which requires wchar support. I'd like to remove eglibc-utils
>>>>> from my distro definition. I could override the default I suspect, but I
>>>>> wonder if eglibc-utils should be made an optional package that distro
>>>>> definitions, images, or users should specifically add if needed?
>>>>>
>>>>> The relevant bit of code appears to be:
>>>>>
>>>>> meta/conf/distro/include/tclibc-eglibc.inc
>>>>>
>>>>> LIBC_DEPENDENCIES = "libsegfault \
>>>>> 		     eglibc \
>>>>>    		     eglibc-dbg \
>>>>>    		     eglibc-dev \
>>>>>    		     eglibc-utils \
>>>>>    		     eglibc-thread-db \
>>>>>    		     eglibc-localedata-i18n \
>>>>>    		     eglibc-gconv-ibm850 \
>>>>>    		     eglibc-gconv-cp1252 \
>>>>>    		     eglibc-gconv-iso8859-1 \
>>>>>    		     eglibc-gconv-iso8859-15 \
>>>>>    		     locale-base-en-us \
>>>>>    		     locale-base-en-gb "
>>>>>
>>>>> eglibc-dbg and eglibc-dev also seem like they could be made optional.
>>>>>
>>>>> Thoughts? Would anyone object to me removing at least eglibc-utils from
>>>>> LIBC_DEPENDENCIES?
>>>>
>>>> I did a little digging:
>>>>
>>>> koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep LIBC_DEPENDENCIES
>>>> meta/conf/distro/include/tclibc-eglibc.inc:LIBC_DEPENDENCIES = "libsegfault \
>>>> meta/conf/distro/include/tclibc-uclibc.inc:LIBC_DEPENDENCIES = "\
>>>> meta/recipes-core/tasks/task-core-nfs.bb:GLIBC_DEPENDENCIES = "glibc-utils"
>>>> meta/recipes-core/tasks/task-core-nfs.bb:RRECOMMENDS_task-core-nfs-server_append_libc-glibc = " ${GLIBC_DEPENDENCIES}"
>>>> meta/recipes-core/tasks/task-core-standalone-sdk-target.bb:    ${LIBC_DEPENDENCIES} \
>>>>
>>>> So it's only used for debug and/or SDK uses. I am going to argue that if you're going to support debug and SDK you're not minimal anymore and can live with bash/gettext/etc.
>>>
>>> Well, nfs isn't SDK only, there are valid deployment uses for that. But
>>> otherwise, agreed.
>>>
>>>>
>>>> Since I was bored I dug up an OE-classic:
>>>>
>>>> koen@dominion:/OE/org.openembedded.dev$ git blame  recipes/tasks/task-sdk-bare.bb
>>>> 749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  1) DESCRIPTION = "Packages for a standalone  SDK or external toolchain"
>>>> [..]
>>>> 9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500  8) GLIBC_PKGS = "\
>>>> 749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  9)     glibc \
>>>> 749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 10)     glibc-dbg \
>>>> 86fa8521 packages/tasks/task-sdk-bare.bb (Tom Rini  2009-02-04 02:07:47 -0500 11)     virtual-libc-dev \
>>>> 749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 12)     glibc-utils \
>>>> 749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 13)     libsegfault \
>>>> 749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 14)     glibc-thread-db \
>>>> f18a05e2 recipes/tasks/task-sdk-bare.bb  (Tom Rini  2010-02-09 16:43:45 -0700 15) "
>>>> 9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500 16) 
>>>> edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 17) LIBC_PKGS_libc-glibc = "${GLIBC_PKGS}"
>>>> edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 18) LIBC_PKGS_libc-uclibc = "uclibc uclibc-dev uclibc-thread-db"
>>>
>>> Was this list used in the same way as LIBC_DEPENDENCIES above?
>>>
>>>>
>>>> So a few years ago that list of packages was only meant for SDK usage.
>>>>
>>>> If you meant GLIBC_DEPENDENCIES (note the extra 'G'), then you need
>>>> to
>>>> check if they are still needed for NFS operation. If so I am going to
>>>> argue that the dependencies should move to the recipes in question
>>>> instead of hiding in the task.
>>>
>>> Right, that makes sense.
>>>
>>>> If it's just a convenience package go
>>>> ahead and remove it, people wanting it can create a new task :)
>>>
>>> Agreed as well.
>>>
>>> I ran into an interesting issue. If I remove eglibc-utils from
>>> LIBC_DEPENDENCIES, it still seems to be getting pulled in, as do bash
>>> and gettext. Still digging to sort out why...
>>
>> It would appear that removing it from LIBC_DEPENDENCIES prevents it from
>> being installed, but it is still built and, worse, so are all of it's
>> RDEPENDS, which pull in bash and gettext and then break on a small libc
>> with no widechar support.
>>
>> So, is it correct behavior to build RDEPENDS for packages that will not
>> be installed?
>>
>> If so, I gather my fix is to remove eglibc-utils from the packages
>> generated by the eglibc recipe when building with my tiny distro?
> 
> What I suspect you're seeing is something like a recipe which does:
> 
> PACKAGES = "A B"
> RDEPENDS_A = "1 2 3"
> RDEPENDS_B = "2 3 4"
> 
> and that you're using A but not B. Since the build system needs to build
> A and B at the same time as they're part of the same recipe, it will
> build 1-4. It won't necessarily install them.
> 
> Usually, if this is causing conflict we'd split the recipe up.

I did the following to eglibc which seems to work:

-PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils eglibc-extra-nss${PKGSU
+PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} eglibc-extra-nss${PKGSUFFIX} eglibc
+
+# eglibc-utils rdepends on bash which depends on gettext which requires wchar
+# support. Only include it in the PACKAGES list if we can build the RDEPENDS.
+PACKAGES += ${@base_contains('DISTRO_FEATURES', 'libc-posix-clang-wchar', '${PN}-utils', '', d)}



-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel



      reply	other threads:[~2011-12-17  2:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 18:30 Can we drop eglibc-utils from LIBC_DEPENDENCIES? Darren Hart
2011-12-16 21:07 ` Koen Kooi
2011-12-16 23:20   ` Darren Hart
2011-12-16 23:34     ` Darren Hart
2011-12-17  1:29       ` Richard Purdie
2011-12-17  2:37         ` Darren Hart [this message]

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=4EEC0060.4050808@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox