[OE-core] meta-toolchain / /bin/sh requirement / ldconfig backfill

[Mark Hatle]

On 9/18/17 3:53 PM, Khem Raj wrote:
> On Mon, Sep 18, 2017 at 12:30 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
>> I tried to build the meta-toolchain, toolchain SDK today and received an error.
>> My system is configured to use package_rpm by default...
>>
>> The error I got was:
>>
>> Error:
>>  Problem: package
>>           packagegroup-core-standalone-sdk-target-1.0-r8.noarch requires
>>           libstdc++6, but none of the providers can be installed
>>   - conflicting requests
>>   - nothing provides /bin/sh needed by libstdc++6-7.2.0-r0.i586
>>
>>
>> The /bin/sh dependency seems kind of odd at first, but after a little research
>> it turns out that by default 'ldconfig' support is now enabled.  This
>> automatically adds a post-install script to any package with a library in it:
>>
>> #!/bin/sh
>> if [ x"$D" = "x" ]; then
>>         if [ -x /sbin/ldconfig ]; then /sbin/ldconfig ; fi
>> fi
>>
>>
>> That in-turn causes the dependency of /bin/sh to occur.
>>
>> Because of this, there is no way (with a default configuration) to build
>> meta-toolchain....
>>
>> Investigating further, ldconfig support moved from "USE_LDCONFIG" to a
>> distribution configuration.  It does this via the "DISTRO_FEATURES_BACKFILL"
>> (introduced in commit: a905df2dd8f43a2febffa64a39b6e508510326a0)
>>
>>
>> If I add to my configuration:
>>
>>  DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig"
>>
>> This works around the issue...  but doesn't resolve the default issue....
>>
>> So my question is, is this behavior (the failure case) really acceptable without
>> telling the user what is happening?  Or do we need to add something to the
>> system that says meta-toolchain can't be used with this DISTRO_FEATURE?  or...
>>
> 
> ldconfig is not very useful with cross toolchain unless its a cross tool too
> I think the particular recipe should check for distro feature before calling
> it out in a post_install

Since it just installs target packages, which causes this issue -- that really
is the problem.

If someone WANTS ldconfig, this could fail for them (without a message
explaining "why").   If someone doesn't want ldconfig, it's not really all that
obvious how to disable it.

I suspect in my own distributions I need to just unconditionally set the
DISTRO_FEATURES_BACKFILL_CONSIDERED line.

--Mark