* [PATCH 0/3] Patches pending on O.S. Systems tree @ 2011-06-01 20:09 Otavio Salvador 2011-06-01 20:09 ` [PATCH 1/3] busybox: enable mdev by default Otavio Salvador ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 20:09 UTC (permalink / raw) To: openembedded-core The following changes since commit 0a496df0209c93fd00ea929b5f27faa1a6e600c0: clutter-1.6: Add patch to update gettext macro version (2011-06-01 18:32:30 +0100) are available in the git repository at: git://github.com/OSSystems/oe-core master https://github.com/OSSystems/oe-core/tree/master Otavio Salvador (3): busybox: enable mdev by default qmake_base.bbclass: fix lrelease/lupdate binary names gnutls: link against 'dl' library meta/classes/qmake_base.bbclass | 5 +++++ meta/recipes-core/busybox/busybox-1.18.4/defconfig | 2 +- meta/recipes-core/busybox/busybox.inc | 1 - meta/recipes-core/busybox/busybox_1.18.4.bb | 2 +- meta/recipes-support/gnutls/gnutls.inc | 4 +++- meta/recipes-support/gnutls/gnutls_2.12.5.bb | 2 +- 6 files changed, 11 insertions(+), 5 deletions(-) -- 1.7.2.5 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/3] busybox: enable mdev by default 2011-06-01 20:09 [PATCH 0/3] Patches pending on O.S. Systems tree Otavio Salvador @ 2011-06-01 20:09 ` Otavio Salvador 2011-06-01 20:37 ` Phil Blundell 2011-06-01 20:09 ` [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names Otavio Salvador 2011-06-01 20:09 ` [PATCH 3/3] gnutls: link against 'dl' library Otavio Salvador 2 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 20:09 UTC (permalink / raw) To: openembedded-core Since we do not require a configuration file by default we don't force it's addition on the package. If the a layer wants to have it enabled it should also set the CONFFILES for busybox-mdev package. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> --- meta/recipes-core/busybox/busybox-1.18.4/defconfig | 2 +- meta/recipes-core/busybox/busybox.inc | 1 - meta/recipes-core/busybox/busybox_1.18.4.bb | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/busybox/busybox-1.18.4/defconfig b/meta/recipes-core/busybox/busybox-1.18.4/defconfig index 5327a64..6b48cc1 100644 --- a/meta/recipes-core/busybox/busybox-1.18.4/defconfig +++ b/meta/recipes-core/busybox/busybox-1.18.4/defconfig @@ -518,7 +518,7 @@ CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y CONFIG_LOSETUP=y # CONFIG_LSPCI is not set # CONFIG_LSUSB is not set -# CONFIG_MDEV is not set +CONFIG_MDEV=y # CONFIG_FEATURE_MDEV_CONF is not set # CONFIG_FEATURE_MDEV_RENAME is not set # CONFIG_FEATURE_MDEV_RENAME_REGEXP is not set diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc index 86fbdae..9b874c5 100644 --- a/meta/recipes-core/busybox/busybox.inc +++ b/meta/recipes-core/busybox/busybox.inc @@ -29,7 +29,6 @@ INITSCRIPT_PARAMS_${PN}-mdev = "start 06 S ." INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd" INITSCRIPT_NAME_${PN}-udhcpc = "busybox-udhcpc" CONFFILES_${PN}-syslog = "${sysconfdir}/syslog.conf.${PN}" -CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf" RRECOMMENDS_${PN} = "${PN}-syslog ${PN}-udhcpc" diff --git a/meta/recipes-core/busybox/busybox_1.18.4.bb b/meta/recipes-core/busybox/busybox_1.18.4.bb index a5080d5..a999490 100644 --- a/meta/recipes-core/busybox/busybox_1.18.4.bb +++ b/meta/recipes-core/busybox/busybox_1.18.4.bb @@ -1,5 +1,5 @@ require busybox.inc -PR = "r2" +PR = "r3" SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \ file://udhcpscript.patch \ -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-01 20:09 ` [PATCH 1/3] busybox: enable mdev by default Otavio Salvador @ 2011-06-01 20:37 ` Phil Blundell 2011-06-01 20:40 ` Otavio Salvador 0 siblings, 1 reply; 29+ messages in thread From: Phil Blundell @ 2011-06-01 20:37 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > -# CONFIG_MDEV is not set > +CONFIG_MDEV=y Per previous discussion, I am still uneasy about this change. I think we really need some sort of coherent policy for what exactly the default busybox configuration in oe-core is meant to be doing, and then (if necessary) a set of patches to make it match the policy. Just flipping random features on and off does not seem like a good way to proceed. p. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-01 20:37 ` Phil Blundell @ 2011-06-01 20:40 ` Otavio Salvador 2011-06-02 16:37 ` Richard Purdie 0 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 20:40 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: > On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: >> -# CONFIG_MDEV is not set >> +CONFIG_MDEV=y > > Per previous discussion, I am still uneasy about this change. I think > we really need some sort of coherent policy for what exactly the default > busybox configuration in oe-core is meant to be doing, and then (if > necessary) a set of patches to make it match the policy. Just flipping > random features on and off does not seem like a good way to proceed. OE-core has support to mdev as device handling mechanism as such this ought to be enabled by default IMO. Personally it doesn't matter since I have already overriden it in my internal layer. -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-01 20:40 ` Otavio Salvador @ 2011-06-02 16:37 ` Richard Purdie 2011-06-02 16:40 ` Otavio Salvador 2011-06-03 1:06 ` Khem Raj 0 siblings, 2 replies; 29+ messages in thread From: Richard Purdie @ 2011-06-02 16:37 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: > On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: > > On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > >> -# CONFIG_MDEV is not set > >> +CONFIG_MDEV=y > > > > Per previous discussion, I am still uneasy about this change. I think > > we really need some sort of coherent policy for what exactly the default > > busybox configuration in oe-core is meant to be doing, and then (if > > necessary) a set of patches to make it match the policy. Just flipping > > random features on and off does not seem like a good way to proceed. > > OE-core has support to mdev as device handling mechanism as such this > ought to be enabled by default IMO. > > Personally it doesn't matter since I have already overriden it in my > internal layer. I'm afraid I'm with Phil on this. I don't like the idea of enabling something we don't actually use. This really needs to become some kind of configure option which would at the same time disable/replace udev so the patch in its currently form isn't acceptable. Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-02 16:37 ` Richard Purdie @ 2011-06-02 16:40 ` Otavio Salvador 2011-06-03 1:06 ` Khem Raj 1 sibling, 0 replies; 29+ messages in thread From: Otavio Salvador @ 2011-06-02 16:40 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, Jun 2, 2011 at 16:37, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > I'm afraid I'm with Phil on this. I don't like the idea of enabling > something we don't actually use. This really needs to become some kind > of configure option which would at the same time disable/replace udev so > the patch in its currently form isn't acceptable. I'll drop it from my tree since I am using an bbappend on our local layer. Cheers, -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-02 16:37 ` Richard Purdie 2011-06-02 16:40 ` Otavio Salvador @ 2011-06-03 1:06 ` Khem Raj 2011-06-03 6:37 ` Koen Kooi 2011-06-03 9:57 ` Phil Blundell 1 sibling, 2 replies; 29+ messages in thread From: Khem Raj @ 2011-06-03 1:06 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: > On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: > > On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: > > > On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > > >> -# CONFIG_MDEV is not set > > >> +CONFIG_MDEV=y > > > > > > Per previous discussion, I am still uneasy about this change. I think > > > we really need some sort of coherent policy for what exactly the > > > default busybox configuration in oe-core is meant to be doing, and > > > then (if necessary) a set of patches to make it match the policy. > > > Just flipping random features on and off does not seem like a good way > > > to proceed. > > > > OE-core has support to mdev as device handling mechanism as such this > > ought to be enabled by default IMO. > > > > Personally it doesn't matter since I have already overriden it in my > > internal layer. > > I'm afraid I'm with Phil on this. I don't like the idea of enabling > something we don't actually use. This really needs to become some kind > of configure option which would at the same time disable/replace udev so > the patch in its currently form isn't acceptable. > mdev or udev are image features so probably should be controlled by IMAGE_FEATURES or some such > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-03 1:06 ` Khem Raj @ 2011-06-03 6:37 ` Koen Kooi 2011-06-03 8:24 ` Richard Purdie 2011-06-03 9:57 ` Phil Blundell 1 sibling, 1 reply; 29+ messages in thread From: Koen Kooi @ 2011-06-03 6:37 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: > On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: >> On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: >>> On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: >>>> On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: >>>>> -# CONFIG_MDEV is not set >>>>> +CONFIG_MDEV=y >>>> >>>> Per previous discussion, I am still uneasy about this change. I think >>>> we really need some sort of coherent policy for what exactly the >>>> default busybox configuration in oe-core is meant to be doing, and >>>> then (if necessary) a set of patches to make it match the policy. >>>> Just flipping random features on and off does not seem like a good way >>>> to proceed. >>> >>> OE-core has support to mdev as device handling mechanism as such this >>> ought to be enabled by default IMO. >>> >>> Personally it doesn't matter since I have already overriden it in my >>> internal layer. >> >> I'm afraid I'm with Phil on this. I don't like the idea of enabling >> something we don't actually use. This really needs to become some kind >> of configure option which would at the same time disable/replace udev so >> the patch in its currently form isn't acceptable. >> > > mdev or udev are image features so probably should be controlled by > IMAGE_FEATURES or some such You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since the packages in the feeds don't magically change when being installed in a different image. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-03 6:37 ` Koen Kooi @ 2011-06-03 8:24 ` Richard Purdie 2011-06-03 8:59 ` Koen Kooi 0 siblings, 1 reply; 29+ messages in thread From: Richard Purdie @ 2011-06-03 8:24 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: > Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: > > > On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: > >> On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: > >>> On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: > >>>> On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > >>>>> -# CONFIG_MDEV is not set > >>>>> +CONFIG_MDEV=y > >>>> > >>>> Per previous discussion, I am still uneasy about this change. I think > >>>> we really need some sort of coherent policy for what exactly the > >>>> default busybox configuration in oe-core is meant to be doing, and > >>>> then (if necessary) a set of patches to make it match the policy. > >>>> Just flipping random features on and off does not seem like a good way > >>>> to proceed. > >>> > >>> OE-core has support to mdev as device handling mechanism as such this > >>> ought to be enabled by default IMO. > >>> > >>> Personally it doesn't matter since I have already overriden it in my > >>> internal layer. > >> > >> I'm afraid I'm with Phil on this. I don't like the idea of enabling > >> something we don't actually use. This really needs to become some kind > >> of configure option which would at the same time disable/replace udev so > >> the patch in its currently form isn't acceptable. > >> > > > > mdev or udev are image features so probably should be controlled by > > IMAGE_FEATURES or some such > > You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since > the packages in the feeds don't magically change when being installed > in a different image. Right, it would have to be a DISTRO_FEATURE for that reason... Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-03 8:24 ` Richard Purdie @ 2011-06-03 8:59 ` Koen Kooi 2011-06-03 9:50 ` Richard Purdie 0 siblings, 1 reply; 29+ messages in thread From: Koen Kooi @ 2011-06-03 8:59 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven: > On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: >> Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: >> >>> On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: >>>> On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: >>>>> On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: >>>>>> On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: >>>>>>> -# CONFIG_MDEV is not set >>>>>>> +CONFIG_MDEV=y >>>>>> >>>>>> Per previous discussion, I am still uneasy about this change. I think >>>>>> we really need some sort of coherent policy for what exactly the >>>>>> default busybox configuration in oe-core is meant to be doing, and >>>>>> then (if necessary) a set of patches to make it match the policy. >>>>>> Just flipping random features on and off does not seem like a good way >>>>>> to proceed. >>>>> >>>>> OE-core has support to mdev as device handling mechanism as such this >>>>> ought to be enabled by default IMO. >>>>> >>>>> Personally it doesn't matter since I have already overriden it in my >>>>> internal layer. >>>> >>>> I'm afraid I'm with Phil on this. I don't like the idea of enabling >>>> something we don't actually use. This really needs to become some kind >>>> of configure option which would at the same time disable/replace udev so >>>> the patch in its currently form isn't acceptable. >>>> >>> >>> mdev or udev are image features so probably should be controlled by >>> IMAGE_FEATURES or some such >> >> You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since >> the packages in the feeds don't magically change when being installed >> in a different image. > > Right, it would have to be a DISTRO_FEATURE for that reason... Right, but you can build mdev and choose not to use it, which is what .dev currently does. So while the distro could in theory set a DISTRO_FEATURE, we shouldn't make other decisions based on that, like deciding that if mdev is in DISTRO_FEATURES every image will use it. regards, Koen ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-03 8:59 ` Koen Kooi @ 2011-06-03 9:50 ` Richard Purdie 2011-06-03 10:42 ` Koen Kooi 0 siblings, 1 reply; 29+ messages in thread From: Richard Purdie @ 2011-06-03 9:50 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Fri, 2011-06-03 at 10:59 +0200, Koen Kooi wrote: > Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven: > > > On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: > >> Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: > >> > >>> On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: > >>>> On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: > >>>>> On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: > >>>>>> On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > >>>>>>> -# CONFIG_MDEV is not set > >>>>>>> +CONFIG_MDEV=y > >>>>>> > >>>>>> Per previous discussion, I am still uneasy about this change. I think > >>>>>> we really need some sort of coherent policy for what exactly the > >>>>>> default busybox configuration in oe-core is meant to be doing, and > >>>>>> then (if necessary) a set of patches to make it match the policy. > >>>>>> Just flipping random features on and off does not seem like a good way > >>>>>> to proceed. > >>>>> > >>>>> OE-core has support to mdev as device handling mechanism as such this > >>>>> ought to be enabled by default IMO. > >>>>> > >>>>> Personally it doesn't matter since I have already overriden it in my > >>>>> internal layer. > >>>> > >>>> I'm afraid I'm with Phil on this. I don't like the idea of enabling > >>>> something we don't actually use. This really needs to become some kind > >>>> of configure option which would at the same time disable/replace udev so > >>>> the patch in its currently form isn't acceptable. > >>>> > >>> > >>> mdev or udev are image features so probably should be controlled by > >>> IMAGE_FEATURES or some such > >> > >> You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since > >> the packages in the feeds don't magically change when being installed > >> in a different image. > > > > Right, it would have to be a DISTRO_FEATURE for that reason... > > Right, but you can build mdev and choose not to use it, which is > what .dev currently does. So while the distro could in theory set a > DISTRO_FEATURE, we shouldn't make other decisions based on that, like > deciding that if mdev is in DISTRO_FEATURES every image will use it. Why we wouldn't enable that functionality based on the option? Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-03 9:50 ` Richard Purdie @ 2011-06-03 10:42 ` Koen Kooi 0 siblings, 0 replies; 29+ messages in thread From: Koen Kooi @ 2011-06-03 10:42 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Op 3 jun 2011, om 11:50 heeft Richard Purdie het volgende geschreven: > On Fri, 2011-06-03 at 10:59 +0200, Koen Kooi wrote: >> Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven: >> >>> On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: >>>> Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: >>>> >>>>> On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: >>>>>> On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: >>>>>>> On Wed, Jun 1, 2011 at 20:37, Phil Blundell <pb@pbcl.net> wrote: >>>>>>>> On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: >>>>>>>>> -# CONFIG_MDEV is not set >>>>>>>>> +CONFIG_MDEV=y >>>>>>>> >>>>>>>> Per previous discussion, I am still uneasy about this change. I think >>>>>>>> we really need some sort of coherent policy for what exactly the >>>>>>>> default busybox configuration in oe-core is meant to be doing, and >>>>>>>> then (if necessary) a set of patches to make it match the policy. >>>>>>>> Just flipping random features on and off does not seem like a good way >>>>>>>> to proceed. >>>>>>> >>>>>>> OE-core has support to mdev as device handling mechanism as such this >>>>>>> ought to be enabled by default IMO. >>>>>>> >>>>>>> Personally it doesn't matter since I have already overriden it in my >>>>>>> internal layer. >>>>>> >>>>>> I'm afraid I'm with Phil on this. I don't like the idea of enabling >>>>>> something we don't actually use. This really needs to become some kind >>>>>> of configure option which would at the same time disable/replace udev so >>>>>> the patch in its currently form isn't acceptable. >>>>>> >>>>> >>>>> mdev or udev are image features so probably should be controlled by >>>>> IMAGE_FEATURES or some such >>>> >>>> You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since >>>> the packages in the feeds don't magically change when being installed >>>> in a different image. >>> >>> Right, it would have to be a DISTRO_FEATURE for that reason... >> >> Right, but you can build mdev and choose not to use it, which is >> what .dev currently does. So while the distro could in theory set a >> DISTRO_FEATURE, we shouldn't make other decisions based on that, like >> deciding that if mdev is in DISTRO_FEATURES every image will use it. > > Why we wouldn't enable that functionality based on the option? I was going to write a lengthy response, but Phil summed it up way too well in http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/003702.html :) ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] busybox: enable mdev by default 2011-06-03 1:06 ` Khem Raj 2011-06-03 6:37 ` Koen Kooi @ 2011-06-03 9:57 ` Phil Blundell 1 sibling, 0 replies; 29+ messages in thread From: Phil Blundell @ 2011-06-03 9:57 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, 2011-06-02 at 18:06 -0700, Khem Raj wrote: > mdev or udev are image features so probably should be controlled by > IMAGE_FEATURES or some such Well, yeah, but this is the thing with busybox: it is a monolithic executable, so you need to decide at configure time what features it's going to include. Although there is a separate busybox-mdev package, it just contains the auxiliary scripting and the bulk of the mdev code goes into busybox itself. This means that making mdev a pure IMAGE_FEATURE isn't practical, since it would basically require mdev to be always compiled in on the offchance that some image might want it. That would lead to code bloat for those images (probably the majority) which don't. Equally, having a single straightforward DISTRO_FEATURE to control mdev is not terribly satisfactory, since some distros might want to configure busybox with mdev enabled but actually use udev (or nothing) for some or all of their images. So, it seems that we really need both: a way for distros to configure whether busybox is built with mdev on or not, and then an IMAGE_FEATURE to control whether any given image gets mdev, or udev, or nothing. The former of those could be done as a DISTRO_FEATURE but, since it's only going to affect busybox, I'm not sure that there is much benefit in doing that; it seems like the distros could just as easily take care of that by direct manipulation of the busybox configuration. p. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names 2011-06-01 20:09 [PATCH 0/3] Patches pending on O.S. Systems tree Otavio Salvador 2011-06-01 20:09 ` [PATCH 1/3] busybox: enable mdev by default Otavio Salvador @ 2011-06-01 20:09 ` Otavio Salvador 2011-06-02 16:51 ` Paul Eggleton 2011-06-01 20:09 ` [PATCH 3/3] gnutls: link against 'dl' library Otavio Salvador 2 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 20:09 UTC (permalink / raw) To: openembedded-core To support translation, qmake based projects usually call lrelease and lupdate however OE changes the binary names so this needs some mangle to work out of box. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> --- meta/classes/qmake_base.bbclass | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/meta/classes/qmake_base.bbclass b/meta/classes/qmake_base.bbclass index a054efd..165d689 100644 --- a/meta/classes/qmake_base.bbclass +++ b/meta/classes/qmake_base.bbclass @@ -92,6 +92,11 @@ qmake_base_do_configure() { bbnote "qmake prevar substitution: ${EXTRA_QMAKEVARS_PRE}" fi + # Hack .pro files to use OE utilities + find -name '*.pro' \ + -exec sed -i -e 's,=\s*.*/lrelease,= ${OE_QMAKE_LRELEASE},g' \ + -e 's,=\s*.*/lupdate,= ${OE_QMAKE_LUPDATE},g' '{}' ';' + #bbnote "Calling '${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o Makefile $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST'" unset QMAKESPEC || true ${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o Makefile $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST || die "Error calling ${OE_QMAKE_QMAKE} on $PROFILES" -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names 2011-06-01 20:09 ` [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names Otavio Salvador @ 2011-06-02 16:51 ` Paul Eggleton 2011-06-02 17:27 ` Richard Purdie 0 siblings, 1 reply; 29+ messages in thread From: Paul Eggleton @ 2011-06-02 16:51 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wednesday 01 June 2011 21:09:54 Otavio Salvador wrote: > To support translation, qmake based projects usually call lrelease and > lupdate however OE changes the binary names so this needs some mangle > to work out of box. > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > --- > meta/classes/qmake_base.bbclass | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/meta/classes/qmake_base.bbclass > b/meta/classes/qmake_base.bbclass index a054efd..165d689 100644 > --- a/meta/classes/qmake_base.bbclass > +++ b/meta/classes/qmake_base.bbclass > @@ -92,6 +92,11 @@ qmake_base_do_configure() { > bbnote "qmake prevar substitution: ${EXTRA_QMAKEVARS_PRE}" > fi > > + # Hack .pro files to use OE utilities > + find -name '*.pro' \ > + -exec sed -i -e 's,=\s*.*/lrelease,= ${OE_QMAKE_LRELEASE},g' \ > + -e 's,=\s*.*/lupdate,= ${OE_QMAKE_LUPDATE},g' '{}' ';' > + > #bbnote "Calling '${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o > Makefile $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST'" unset > QMAKESPEC || true > ${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o Makefile > $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST || die "Error > calling ${OE_QMAKE_QMAKE} on $PROFILES" Acked-by: Paul Eggleton <paul.eggleton@linux.intel.com> -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names 2011-06-02 16:51 ` Paul Eggleton @ 2011-06-02 17:27 ` Richard Purdie 0 siblings, 0 replies; 29+ messages in thread From: Richard Purdie @ 2011-06-02 17:27 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, 2011-06-02 at 17:51 +0100, Paul Eggleton wrote: > On Wednesday 01 June 2011 21:09:54 Otavio Salvador wrote: > > To support translation, qmake based projects usually call lrelease and > > lupdate however OE changes the binary names so this needs some mangle > > to work out of box. > > > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > > --- > > meta/classes/qmake_base.bbclass | 5 +++++ > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > diff --git a/meta/classes/qmake_base.bbclass > > b/meta/classes/qmake_base.bbclass index a054efd..165d689 100644 > > --- a/meta/classes/qmake_base.bbclass > > +++ b/meta/classes/qmake_base.bbclass > > @@ -92,6 +92,11 @@ qmake_base_do_configure() { > > bbnote "qmake prevar substitution: ${EXTRA_QMAKEVARS_PRE}" > > fi > > > > + # Hack .pro files to use OE utilities > > + find -name '*.pro' \ > > + -exec sed -i -e 's,=\s*.*/lrelease,= ${OE_QMAKE_LRELEASE},g' \ > > + -e 's,=\s*.*/lupdate,= ${OE_QMAKE_LUPDATE},g' '{}' ';' > > + > > #bbnote "Calling '${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o > > Makefile $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST'" unset > > QMAKESPEC || true > > ${OE_QMAKE_QMAKE} -makefile -spec ${QMAKESPEC} -o Makefile > > $QMAKE_VARSUBST_PRE $AFTER $PROFILES $QMAKE_VARSUBST_POST || die "Error > > calling ${OE_QMAKE_QMAKE} on $PROFILES" > > Acked-by: Paul Eggleton <paul.eggleton@linux.intel.com> Merged to master, thanks. Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 20:09 [PATCH 0/3] Patches pending on O.S. Systems tree Otavio Salvador 2011-06-01 20:09 ` [PATCH 1/3] busybox: enable mdev by default Otavio Salvador 2011-06-01 20:09 ` [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names Otavio Salvador @ 2011-06-01 20:09 ` Otavio Salvador 2011-06-01 20:33 ` Phil Blundell 2 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 20:09 UTC (permalink / raw) To: openembedded-core Fixes a build failure due missing references to 'dlopen' and like. This started to happen after update to 2.12.5 at ad52eacebdc413aa351de078ee878182a9c71e16. This also fixes the recipe to use the INC_PR value otherwise we end not bumping PR if changing only the '.inc' file. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> --- meta/recipes-support/gnutls/gnutls.inc | 4 +++- meta/recipes-support/gnutls/gnutls_2.12.5.bb | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc index 9f8d81b..9452190 100644 --- a/meta/recipes-support/gnutls/gnutls.inc +++ b/meta/recipes-support/gnutls/gnutls.inc @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.gnu.org/software/gnutls/" BUGTRACKER = "https://savannah.gnu.org/support/?group=gnutls" DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap" -INC_PR = "r1" +INC_PR = "r2" LICENSE = "GPLv3+ & LGPLv2.1+" LICENSE_${PN} = "LGPLv2.1+" @@ -30,6 +30,8 @@ do_configure_prepend() { done } +export LDFLAGS += "-ldl" + PACKAGES =+ "${PN}-openssl ${PN}-extra ${PN}-bin ${PN}-xx" FILES_${PN} = "${libdir}/libgnutls.so.*" diff --git a/meta/recipes-support/gnutls/gnutls_2.12.5.bb b/meta/recipes-support/gnutls/gnutls_2.12.5.bb index b27a065..9d3f5ab 100644 --- a/meta/recipes-support/gnutls/gnutls_2.12.5.bb +++ b/meta/recipes-support/gnutls/gnutls_2.12.5.bb @@ -1,6 +1,6 @@ require gnutls.inc -PR = "r0" +PR = "${INC_PR}.0" SRC_URI += "file://gnutls-openssl.patch \ file://configure-fix.patch" -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 20:09 ` [PATCH 3/3] gnutls: link against 'dl' library Otavio Salvador @ 2011-06-01 20:33 ` Phil Blundell 2011-06-01 20:39 ` Otavio Salvador 0 siblings, 1 reply; 29+ messages in thread From: Phil Blundell @ 2011-06-01 20:33 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > +export LDFLAGS += "-ldl" The configure script ought to be figuring this out for itself. Do you know why that isn't working? p. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 20:33 ` Phil Blundell @ 2011-06-01 20:39 ` Otavio Salvador 2011-06-01 20:53 ` Phil Blundell 0 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 20:39 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, Jun 1, 2011 at 20:33, Phil Blundell <pb@pbcl.net> wrote: > On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: >> +export LDFLAGS += "-ldl" > > The configure script ought to be figuring this out for itself. Do you > know why that isn't working? No I don't. Are you able to reproduce it? -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 20:39 ` Otavio Salvador @ 2011-06-01 20:53 ` Phil Blundell 2011-06-01 21:00 ` Otavio Salvador 0 siblings, 1 reply; 29+ messages in thread From: Phil Blundell @ 2011-06-01 20:53 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: > On Wed, Jun 1, 2011 at 20:33, Phil Blundell <pb@pbcl.net> wrote: > > On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: > >> +export LDFLAGS += "-ldl" > > > > The configure script ought to be figuring this out for itself. Do you > > know why that isn't working? > > No I don't. > > Are you able to reproduce it? No, it works fine for me. I get: checking how to link with libpthread... -lpthread checking for libdl... yes checking how to link with libdl... -ldl checking whether we are using the GNU C++ compiler... yes This is with the current head of oe-core on qemuarm. p. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 20:53 ` Phil Blundell @ 2011-06-01 21:00 ` Otavio Salvador 2011-06-01 21:43 ` Saul Wold 0 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2011-06-01 21:00 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, Jun 1, 2011 at 20:53, Phil Blundell <pb@pbcl.net> wrote: > On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: >> Are you able to reproduce it? > > No, it works fine for me. I get: > > checking how to link with libpthread... -lpthread > checking for libdl... yes > checking how to link with libdl... -ldl > checking whether we are using the GNU C++ compiler... yes > > This is with the current head of oe-core on qemuarm. I am building for i586 but I doubt it is related. I get: checking for libpthread... yes checking how to link with libpthread... /usr/lib/libpthread.so checking for libdl... no checking whether we are using the GNU C++ compiler... yes -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 21:00 ` Otavio Salvador @ 2011-06-01 21:43 ` Saul Wold 2011-06-01 21:52 ` Martin Jansa 0 siblings, 1 reply; 29+ messages in thread From: Saul Wold @ 2011-06-01 21:43 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On 06/01/2011 02:00 PM, Otavio Salvador wrote: > On Wed, Jun 1, 2011 at 20:53, Phil Blundell<pb@pbcl.net> wrote: >> On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: >>> Are you able to reproduce it? >> >> No, it works fine for me. I get: >> >> checking how to link with libpthread... -lpthread >> checking for libdl... yes >> checking how to link with libdl... -ldl >> checking whether we are using the GNU C++ compiler... yes >> >> This is with the current head of oe-core on qemuarm. > > I am building for i586 but I doubt it is related. > > I get: > > checking for libpthread... yes > checking how to link with libpthread... /usr/lib/libpthread.so > checking for libdl... no > checking whether we are using the GNU C++ compiler... yes > I also built for x86 and beagle, both have libdl, can you check that you do not have some kind of site configuration that is overriding, also maybe post your log from .../gnutls-2.12.5/lib/config.log Thanks Sau! ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 21:43 ` Saul Wold @ 2011-06-01 21:52 ` Martin Jansa 2011-06-01 22:19 ` Saul Wold 0 siblings, 1 reply; 29+ messages in thread From: Martin Jansa @ 2011-06-01 21:52 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1626 bytes --] On Wed, Jun 01, 2011 at 02:43:53PM -0700, Saul Wold wrote: > On 06/01/2011 02:00 PM, Otavio Salvador wrote: > > On Wed, Jun 1, 2011 at 20:53, Phil Blundell<pb@pbcl.net> wrote: > >> On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: > >>> Are you able to reproduce it? > >> > >> No, it works fine for me. I get: > >> > >> checking how to link with libpthread... -lpthread > >> checking for libdl... yes > >> checking how to link with libdl... -ldl > >> checking whether we are using the GNU C++ compiler... yes > >> > >> This is with the current head of oe-core on qemuarm. > > > > I am building for i586 but I doubt it is related. > > > > I get: > > > > checking for libpthread... yes > > checking how to link with libpthread... /usr/lib/libpthread.so > > checking for libdl... no > > checking whether we are using the GNU C++ compiler... yes > > > I also built for x86 and beagle, both have libdl, can you check that you > do not have some kind of site configuration that is overriding, also > maybe post your log from .../gnutls-2.12.5/lib/config.log here it tries to link against host libdl configure:26050: checking for libdl configure:26069: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t --sysroot=/OE/shr-core/tmp/sysroots/om-gta02 -o conftest -O2 -pipe -g -feliminate-unused-debug-types -I/OE/shr-core/tmp/sysroots/om-gta02/usr/include -Wl,-O1 -Wl,--as-needed conftest.c /usr/lib/libdl.so >&5 /usr/lib/libdl.so: file not recognized: File format not recognized collect2: ld returned 1 exit status -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 21:52 ` Martin Jansa @ 2011-06-01 22:19 ` Saul Wold 2011-06-02 6:31 ` Martin Jansa 0 siblings, 1 reply; 29+ messages in thread From: Saul Wold @ 2011-06-01 22:19 UTC (permalink / raw) To: openembedded-core On 06/01/2011 02:52 PM, Martin Jansa wrote: > On Wed, Jun 01, 2011 at 02:43:53PM -0700, Saul Wold wrote: >> On 06/01/2011 02:00 PM, Otavio Salvador wrote: >>> On Wed, Jun 1, 2011 at 20:53, Phil Blundell<pb@pbcl.net> wrote: >>>> On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: >>>>> Are you able to reproduce it? >>>> >>>> No, it works fine for me. I get: >>>> >>>> checking how to link with libpthread... -lpthread >>>> checking for libdl... yes >>>> checking how to link with libdl... -ldl >>>> checking whether we are using the GNU C++ compiler... yes >>>> >>>> This is with the current head of oe-core on qemuarm. >>> >>> I am building for i586 but I doubt it is related. >>> >>> I get: >>> >>> checking for libpthread... yes >>> checking how to link with libpthread... /usr/lib/libpthread.so >>> checking for libdl... no >>> checking whether we are using the GNU C++ compiler... yes >>> >> I also built for x86 and beagle, both have libdl, can you check that you >> do not have some kind of site configuration that is overriding, also >> maybe post your log from .../gnutls-2.12.5/lib/config.log > > here it tries to link against host libdl > > configure:26050: checking for libdl > configure:26069: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t > --sysroot=/OE/shr-core/tmp/sysroots/om-gta02 -o conftest -O2 -pipe -g > -feliminate-unused-debug-types > -I/OE/shr-core/tmp/sysroots/om-gta02/usr/include -Wl,-O1 > -Wl,--as-needed conftest.c /usr/lib/libdl.so>&5 > /usr/lib/libdl.so: file not recognized: File format not recognized > collect2: ld returned 1 exit status > Well that's interesting, since I see it linking using -ldl, there must be some other setting that's affecting this, I have been looking in gnutls to see if I can find something else that sets libdl.so vs -ldl, I have not found it. configure:26075: i586-poky-linux-gcc -march=i586 --sysroot=/builds/world/tmp/sysroots/qemux86 -o conftest -O2 -pipe -g -feliminate-unused-debug-types -I/builds/world/tmp/sysroots/qemux86/usr/include -Wl,-O1 -Wl,--as-needed conftest.c -ldl >&5 configure:26075: $? = 0 configure:26085: result: yes configure:26092: checking how to link with libdl configure:26094: result: -ldl Sau! > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-01 22:19 ` Saul Wold @ 2011-06-02 6:31 ` Martin Jansa 2011-06-02 9:29 ` Koen Kooi 2011-06-02 9:38 ` Richard Purdie 0 siblings, 2 replies; 29+ messages in thread From: Martin Jansa @ 2011-06-02 6:31 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3307 bytes --] On Wed, Jun 01, 2011 at 03:19:18PM -0700, Saul Wold wrote: > On 06/01/2011 02:52 PM, Martin Jansa wrote: > > On Wed, Jun 01, 2011 at 02:43:53PM -0700, Saul Wold wrote: > >> On 06/01/2011 02:00 PM, Otavio Salvador wrote: > >>> On Wed, Jun 1, 2011 at 20:53, Phil Blundell<pb@pbcl.net> wrote: > >>>> On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: > >>>>> Are you able to reproduce it? > >>>> > >>>> No, it works fine for me. I get: > >>>> > >>>> checking how to link with libpthread... -lpthread > >>>> checking for libdl... yes > >>>> checking how to link with libdl... -ldl > >>>> checking whether we are using the GNU C++ compiler... yes > >>>> > >>>> This is with the current head of oe-core on qemuarm. > >>> > >>> I am building for i586 but I doubt it is related. > >>> > >>> I get: > >>> > >>> checking for libpthread... yes > >>> checking how to link with libpthread... /usr/lib/libpthread.so > >>> checking for libdl... no > >>> checking whether we are using the GNU C++ compiler... yes > >>> > >> I also built for x86 and beagle, both have libdl, can you check that you > >> do not have some kind of site configuration that is overriding, also > >> maybe post your log from .../gnutls-2.12.5/lib/config.log > > > > here it tries to link against host libdl > > > > configure:26050: checking for libdl > > configure:26069: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t > > --sysroot=/OE/shr-core/tmp/sysroots/om-gta02 -o conftest -O2 -pipe -g > > -feliminate-unused-debug-types > > -I/OE/shr-core/tmp/sysroots/om-gta02/usr/include -Wl,-O1 > > -Wl,--as-needed conftest.c /usr/lib/libdl.so>&5 > > /usr/lib/libdl.so: file not recognized: File format not recognized > > collect2: ld returned 1 exit status > > > Well that's interesting, since I see it linking using -ldl, there must > be some other setting that's affecting this, I have been looking in > gnutls to see if I can find something else that sets libdl.so vs -ldl, > I have not found it. > > configure:26075: i586-poky-linux-gcc -march=i586 > --sysroot=/builds/world/tmp/sysroots/qemux86 -o conftest -O2 -pipe -g > -feliminate-unused-debug-types > -I/builds/world/tmp/sysroots/qemux86/usr/include -Wl,-O1 > -Wl,--as-needed conftest.c -ldl >&5 > configure:26075: $? = 0 > configure:26085: result: yes > configure:26092: checking how to link with libdl > configure:26094: result: -ldl what do you have in configlog for LIBDL? here it's all empty LIBDL='' LIBDL_PREFIX='' LTLIBDL='' if I add + --with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \ + --with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \ to EXTRA_OE_CONF (we already have couple of --with-*-prefix there) it's found correctly (and this is at least better workarround then forcing -ldl directly to LDFLAGS): LIBDL='/OE/shr-core/tmp/sysroots/om-gta02/usr/lib/libdl.so' LIBDL_PREFIX='/OE/shr-core/tmp/sysroots/om-gta02/usr' LTLIBDL='-L/OE/shr-core/tmp/sysroots/om-gta02/usr/lib -ldl' same problem is with libpthread.. maybe their m4/lib-link.m4 does something wrong in AC_DEFUN([AC_LIB_HAVE_LINKFLAGS], [ AC_REQUIRE([AC_LIB_PREPARE_PREFIX]) AC_REQUIRE([AC_LIB_RPATH]) Regards, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-02 6:31 ` Martin Jansa @ 2011-06-02 9:29 ` Koen Kooi 2011-06-02 9:38 ` Richard Purdie 1 sibling, 0 replies; 29+ messages in thread From: Koen Kooi @ 2011-06-02 9:29 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Op 2 jun 2011, om 08:31 heeft Martin Jansa het volgende geschreven: > On Wed, Jun 01, 2011 at 03:19:18PM -0700, Saul Wold wrote: >> On 06/01/2011 02:52 PM, Martin Jansa wrote: >>> On Wed, Jun 01, 2011 at 02:43:53PM -0700, Saul Wold wrote: >>>> On 06/01/2011 02:00 PM, Otavio Salvador wrote: >>>>> On Wed, Jun 1, 2011 at 20:53, Phil Blundell<pb@pbcl.net> wrote: >>>>>> On Wed, 2011-06-01 at 20:39 +0000, Otavio Salvador wrote: >>>>>>> Are you able to reproduce it? >>>>>> >>>>>> No, it works fine for me. I get: >>>>>> >>>>>> checking how to link with libpthread... -lpthread >>>>>> checking for libdl... yes >>>>>> checking how to link with libdl... -ldl >>>>>> checking whether we are using the GNU C++ compiler... yes >>>>>> >>>>>> This is with the current head of oe-core on qemuarm. >>>>> >>>>> I am building for i586 but I doubt it is related. >>>>> >>>>> I get: >>>>> >>>>> checking for libpthread... yes >>>>> checking how to link with libpthread... /usr/lib/libpthread.so >>>>> checking for libdl... no >>>>> checking whether we are using the GNU C++ compiler... yes >>>>> >>>> I also built for x86 and beagle, both have libdl, can you check that you >>>> do not have some kind of site configuration that is overriding, also >>>> maybe post your log from .../gnutls-2.12.5/lib/config.log >>> >>> here it tries to link against host libdl >>> >>> configure:26050: checking for libdl >>> configure:26069: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t >>> --sysroot=/OE/shr-core/tmp/sysroots/om-gta02 -o conftest -O2 -pipe -g >>> -feliminate-unused-debug-types >>> -I/OE/shr-core/tmp/sysroots/om-gta02/usr/include -Wl,-O1 >>> -Wl,--as-needed conftest.c /usr/lib/libdl.so>&5 >>> /usr/lib/libdl.so: file not recognized: File format not recognized >>> collect2: ld returned 1 exit status >>> >> Well that's interesting, since I see it linking using -ldl, there must >> be some other setting that's affecting this, I have been looking in >> gnutls to see if I can find something else that sets libdl.so vs -ldl, >> I have not found it. >> >> configure:26075: i586-poky-linux-gcc -march=i586 >> --sysroot=/builds/world/tmp/sysroots/qemux86 -o conftest -O2 -pipe -g >> -feliminate-unused-debug-types >> -I/builds/world/tmp/sysroots/qemux86/usr/include -Wl,-O1 >> -Wl,--as-needed conftest.c -ldl >&5 >> configure:26075: $? = 0 >> configure:26085: result: yes >> configure:26092: checking how to link with libdl >> configure:26094: result: -ldl > > what do you have in configlog for LIBDL? > > here it's all empty > LIBDL='' > LIBDL_PREFIX='' > LTLIBDL='' I get for cross gnutls in lib/config.log: grep LIBDL lib/config.log HAVE_LIBDL='no' LIBDL='' LIBDL_PREFIX='' LTLIBDL='' regards, Koen ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] gnutls: link against 'dl' library 2011-06-02 6:31 ` Martin Jansa 2011-06-02 9:29 ` Koen Kooi @ 2011-06-02 9:38 ` Richard Purdie 2011-06-02 11:00 ` [PATCH] gnutls: add --with-libdl-prefix and --with-libpthread-prefix Martin Jansa 1 sibling, 1 reply; 29+ messages in thread From: Richard Purdie @ 2011-06-02 9:38 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, 2011-06-02 at 08:31 +0200, Martin Jansa wrote: > what do you have in configlog for LIBDL? > > here it's all empty > LIBDL='' > LIBDL_PREFIX='' > LTLIBDL='' > > if I add > + --with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \ > + --with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \ > to EXTRA_OE_CONF (we already have couple of --with-*-prefix there) it's > found correctly (and this is at least better workarround then forcing > -ldl directly to LDFLAGS): > LIBDL='/OE/shr-core/tmp/sysroots/om-gta02/usr/lib/libdl.so' > LIBDL_PREFIX='/OE/shr-core/tmp/sysroots/om-gta02/usr' > LTLIBDL='-L/OE/shr-core/tmp/sysroots/om-gta02/usr/lib -ldl' > > same problem is with libpthread.. > > maybe their m4/lib-link.m4 does something wrong in > AC_DEFUN([AC_LIB_HAVE_LINKFLAGS], > [ > AC_REQUIRE([AC_LIB_PREPARE_PREFIX]) > AC_REQUIRE([AC_LIB_RPATH]) I just looked at the code in lib/configure and concluded that its just luck whether it figures out the correct values or does something really nasty. Its poking about ${libdir} for this stuff so you end up with something like the following combinations: a) 64 bit system with 64 bit libs in /usr/lib64 and no 32 bit libs: Finds no -ldl Something else may or may not link it indirectly so the build may or may not work. b) 64 bit system with 64 bit libs in /usr/lib64 and 32 bit libs in /usr/lib, building for 32 bit: Finds a -ldl which "works". Things appear to work. c) Other variations The correct fix would appear to be to set the paths specifically using the options Martin mentions above. Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH] gnutls: add --with-libdl-prefix and --with-libpthread-prefix 2011-06-02 9:38 ` Richard Purdie @ 2011-06-02 11:00 ` Martin Jansa 2011-06-02 13:53 ` Richard Purdie 0 siblings, 1 reply; 29+ messages in thread From: Martin Jansa @ 2011-06-02 11:00 UTC (permalink / raw) To: openembedded-core Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- meta/recipes-support/gnutls/gnutls.inc | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc index 9f8d81b..03aed6a 100644 --- a/meta/recipes-support/gnutls/gnutls.inc +++ b/meta/recipes-support/gnutls/gnutls.inc @@ -22,6 +22,8 @@ inherit autotools binconfig pkgconfig gettext EXTRA_OECONF="--with-included-opencdk --with-included-libcfg --disable-rpath \ --with-libtasn1-prefix=${STAGING_DIR_HOST}${prefix} \ --with-libgcrypt --with-libgcrypt-prefix=${STAGING_DIR_HOST}${prefix} \ + --with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \ + --with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \ --with-lzo --disable-guile \ " do_configure_prepend() { -- 1.7.5.3 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH] gnutls: add --with-libdl-prefix and --with-libpthread-prefix 2011-06-02 11:00 ` [PATCH] gnutls: add --with-libdl-prefix and --with-libpthread-prefix Martin Jansa @ 2011-06-02 13:53 ` Richard Purdie 0 siblings, 0 replies; 29+ messages in thread From: Richard Purdie @ 2011-06-02 13:53 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, 2011-06-02 at 13:00 +0200, Martin Jansa wrote: > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> > --- > meta/recipes-support/gnutls/gnutls.inc | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc > index 9f8d81b..03aed6a 100644 > --- a/meta/recipes-support/gnutls/gnutls.inc > +++ b/meta/recipes-support/gnutls/gnutls.inc > @@ -22,6 +22,8 @@ inherit autotools binconfig pkgconfig gettext > EXTRA_OECONF="--with-included-opencdk --with-included-libcfg --disable-rpath \ > --with-libtasn1-prefix=${STAGING_DIR_HOST}${prefix} \ > --with-libgcrypt --with-libgcrypt-prefix=${STAGING_DIR_HOST}${prefix} \ > + --with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \ > + --with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \ > --with-lzo --disable-guile \ > " > do_configure_prepend() { Merged to master, thanks. Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-06-03 10:45 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-06-01 20:09 [PATCH 0/3] Patches pending on O.S. Systems tree Otavio Salvador 2011-06-01 20:09 ` [PATCH 1/3] busybox: enable mdev by default Otavio Salvador 2011-06-01 20:37 ` Phil Blundell 2011-06-01 20:40 ` Otavio Salvador 2011-06-02 16:37 ` Richard Purdie 2011-06-02 16:40 ` Otavio Salvador 2011-06-03 1:06 ` Khem Raj 2011-06-03 6:37 ` Koen Kooi 2011-06-03 8:24 ` Richard Purdie 2011-06-03 8:59 ` Koen Kooi 2011-06-03 9:50 ` Richard Purdie 2011-06-03 10:42 ` Koen Kooi 2011-06-03 9:57 ` Phil Blundell 2011-06-01 20:09 ` [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names Otavio Salvador 2011-06-02 16:51 ` Paul Eggleton 2011-06-02 17:27 ` Richard Purdie 2011-06-01 20:09 ` [PATCH 3/3] gnutls: link against 'dl' library Otavio Salvador 2011-06-01 20:33 ` Phil Blundell 2011-06-01 20:39 ` Otavio Salvador 2011-06-01 20:53 ` Phil Blundell 2011-06-01 21:00 ` Otavio Salvador 2011-06-01 21:43 ` Saul Wold 2011-06-01 21:52 ` Martin Jansa 2011-06-01 22:19 ` Saul Wold 2011-06-02 6:31 ` Martin Jansa 2011-06-02 9:29 ` Koen Kooi 2011-06-02 9:38 ` Richard Purdie 2011-06-02 11:00 ` [PATCH] gnutls: add --with-libdl-prefix and --with-libpthread-prefix Martin Jansa 2011-06-02 13:53 ` Richard Purdie
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.