[OE-core] [PATCH 1/2] uclibc.inc: uclibc rtld does support GNU_HASH

[Marko Lindqvist]

On 9 May 2012 17:49, Mark Hatle <mark.hatle at windriver.com> wrote:
> On 5/8/12 9:09 PM, Khem Raj wrote:
>>
>> On Tue, May 8, 2012 at 6:53 PM, Marko Lindqvist<cazfi74 at gmail.com>  wrote:
>>>
>>> On 9 May 2012 04:36, Khem Raj<raj.khem at gmail.com>  wrote:
>>>>
>>>> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist<cazfi74 at gmail.com>
>>>>  wrote:
>>>>>
>>>>>
>>>>>
>>>>>  You should know that I'm just figuring out what to do with
>>>>> "rtld(GNU_HASH)" that already exist for eglibc. When building
>>>>> deb-packets based image, that results in:
>>>>> "reference to 'rtld': error in version: version number does not start
>>>>> with digit"
>>>>>
>>>>>  I've confirmed that error message is caused by this by simply
>>>>> removing "(GNU_HASH)" ->  eglibc build success
>>>>
>>>>
>>>> yeah this is rpm brain damage actually that we are dealing with here.
>>>> I think rpm should be fixed for this. I am not entirely sure why this
>>>> would be needed on current OE-Core lets say if its needed it should then
>>>> be made specific when someone is using rpm for packaging.
>>>
>>>
>>>  I've not yet figured out what all this tries to achieve, but are you
>>> saying that it might be acceptable solution for eglibc too to simply
>>> remove "(GNU_HASH)" if nobody from rpm world vetoes such patch?
>>
>>
>> yes. We need to find why this PROVIDE is needed at all in current OE
>
> The per-file "advanced" dependencies, which are not yet being used by ipkg
> or deb, include a marker for rtld support.  The libc on the system needs to
> have a provide that it supports GNU_HASH, otherwise a missing dependency
> occurs and the system knows the package and libc has a mismatch.
>
> IPKG works with this, but apparently DEB does not.  We have two solutions
> that I see.
>
> If the format of the RPROVIDE is legal in OE, then the DEB package solution
> needs to transform the provide into something that is legal for debian style
> packages.
>
> If the format of the RPROVIDE is illegal in OE (and just happens to work),
> then the RPM package manager needs to transform the provide...
>
> RPM is already doing a number of transforms to change from OE format to RPM
> format, I would expect the same behavior from other package managers --
> assuming that the RPROVIDE is legal.
>
> Who can definitively state what the legal RPROVIDE format is in OE?

 If we are to define it now, and selecting from existing alternatives,
parenthesis could denote either:

deb style) Single version number override. Recipe 1.0.0 can provide
some 1.0.1 package.

rpm style) General marker (does it even handle multiple ones?)


 Any use-case relevant to OE I see for deb style handling can be
handled with smart use of rpm style, but not the other way around.



 - ML