Patchwork [1/2] uclibc.inc: uclibc rtld does support GNU_HASH

login
register
mail settings
Submitter Khem Raj
Date May 9, 2012, 12:43 a.m.
Message ID <fa8d138dc96a622f36b8783457c375186a84e411.1336524034.git.raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/27331/
State Accepted
Commit a4b74a8244e8b55075082e6d5a59f35f8e437e9d
Headers show

Comments

Khem Raj - May 9, 2012, 12:43 a.m.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-core/uclibc/uclibc.inc |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
Marko Lindqvist - May 9, 2012, 12:59 a.m.
On 9 May 2012 03:43, Khem Raj <raj.khem@gmail.com> wrote:
> -RPROVIDES_uclibc += "libsegfault"
> +
> +RPROVIDES_uclibc += "libsegfault rtld(GNU_HASH)"

 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


 - ML
Khem Raj - May 9, 2012, 1:36 a.m.
On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist <cazfi74@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.
Marko Lindqvist - May 9, 2012, 1:53 a.m.
On 9 May 2012 04:36, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist <cazfi74@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?


 - ML
Khem Raj - May 9, 2012, 2:09 a.m.
On Tue, May 8, 2012 at 6:53 PM, Marko Lindqvist <cazfi74@gmail.com> wrote:
> On 9 May 2012 04:36, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist <cazfi74@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
Mark Hatle - May 9, 2012, 2:49 p.m.
On 5/8/12 9:09 PM, Khem Raj wrote:
> On Tue, May 8, 2012 at 6:53 PM, Marko Lindqvist<cazfi74@gmail.com>  wrote:
>> On 9 May 2012 04:36, Khem Raj<raj.khem@gmail.com>  wrote:
>>> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist<cazfi74@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?

--Mark

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Marko Lindqvist - May 9, 2012, 3:46 p.m.
On 9 May 2012 17:49, Mark Hatle <mark.hatle@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@gmail.com>  wrote:
>>>
>>> On 9 May 2012 04:36, Khem Raj<raj.khem@gmail.com>  wrote:
>>>>
>>>> On Tue, May 8, 2012 at 5:59 PM, Marko Lindqvist<cazfi74@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
Khem Raj - May 9, 2012, 3:47 p.m.
On Wed, May 9, 2012 at 7:49 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 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.

I would assume that this was needed when transition for sysv hash to
gnu hash was going on. Now that GNU_HASH is default in OE for long
time this kind of
makes it redundant unless I am missing something w.r.t. advanced dependency
support. What is it exactly doing ?
Mark Hatle - May 9, 2012, 3:55 p.m.
On 5/9/12 10:47 AM, Khem Raj wrote:
> On Wed, May 9, 2012 at 7:49 AM, Mark Hatle<mark.hatle@windriver.com>  wrote:
>> 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.
>
> I would assume that this was needed when transition for sysv hash to
> gnu hash was going on. Now that GNU_HASH is default in OE for long
> time this kind of
> makes it redundant unless I am missing something w.r.t. advanced dependency
> support. What is it exactly doing ?

In the RPM case it was for people who download random binary packages from 
upstream sources and attempt to install them.  If the local system doesn't 
support GNU_HASH then it won't work.

I thought it was still possible to build and configure a system w/ no GNU_HASH 
dependencies (or even support).

I know OE itself probably doesn't have this problem, OE-Core certainly 
shouldn't.. but it's external binary package cases that cause problems.

--Mark

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Marko Lindqvist - May 9, 2012, 11:57 p.m.
On 9 May 2012 18:46, Marko Lindqvist <cazfi74@gmail.com> wrote:
> On 9 May 2012 17:49, Mark Hatle <mark.hatle@windriver.com> wrote:
>>
>> 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.

 Working on assumption that deb-side was the broken one, I submitted
patch http://patchwork.openembedded.org/patch/27417/


 - ML

Patch

diff --git a/meta/recipes-core/uclibc/uclibc.inc b/meta/recipes-core/uclibc/uclibc.inc
index f5b6bf7..55ab0c9 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -88,7 +88,8 @@  RPROVIDES_${PN}-dev += "libc-dev virtual-libc-dev"
 # uclibc does not really have libsegfault but then using the one from glibc is also not
 # going to work. So we pretend that we have it to make bitbake not pull other recipes
 # to satisfy this dependency for the images/tasks
-RPROVIDES_uclibc += "libsegfault"
+
+RPROVIDES_uclibc += "libsegfault rtld(GNU_HASH)"
 
 SRC_URI = "\
         http://www.uclibc.org/downloads/uClibc-${PV}.tar.bz2;name=uClibc-${PV} \