Patches pending on O.S. Systems tree

PATCH Applied Otavio Salvador 8 participants 29 messages Jun 1, 2011 – Jun 3, 2011

lore

Share & tools

lore

Otavio Salvador

author

2011-06-01 20:13 UTC #0 lore raw

cover Patches pending on O.S. Systems tree

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(-)

Signature · 1 line

1.7.2.5

Otavio Salvador

author

2011-06-01 20:13 UTC #1 lore raw

PATCH 1/3 busybox: enable mdev by default

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 <[email protected]>

---
 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(-)

meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1

index 5327a64..6b48cc1 100644
@@ -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

meta/recipes-core/busybox/busybox.inc +0 -1

index 86fbdae..9b874c5 100644
@@ -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"

meta/recipes-core/busybox/busybox_1.18.4.bb +1 -1

index a5080d5..a999490 100644
@@ -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 \

Signature · 1 line

1.7.2.5

Phil Blundell

2011-06-01 20:40 UTC #2 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

meta/recipes-core/busybox/busybox-1.18.4/defconfig CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y · line 521

Quoted 2 lines · Otavio Salvador

meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1
-# 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.

Otavio Salvador

author

2011-06-01 20:44 UTC #3 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Quoted 9 lines · Phil Blundell

meta/recipes-core/busybox/busybox-1.18.4/defconfig CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y · line 521
Quoted 2 lines · Otavio Salvador
meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1
-# 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.

Signature · 3 lines

Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Richard Purdie

2011-06-02 16:41 UTC #4 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Quoted 11 lines · Otavio Salvador

Quoted 9 lines · Phil Blundell
meta/recipes-core/busybox/busybox-1.18.4/defconfig CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y · line 521
Quoted 2 lines · Otavio Salvador
meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1
-# 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.

Quoted 5 lines

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

Otavio Salvador

author

2011-06-02 16:43 UTC #5 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Quoted 4 lines · Richard Purdie

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,

Signature · 3 lines

Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Khem Raj

2011-06-03 01:09 UTC #6 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

In reply to Richard Purdie

Quoted 16 lines · Richard Purdie

Quoted 15 lines · Otavio Salvador
Quoted 10 lines · Phil Blundell
meta/recipes-core/busybox/busybox-1.18.4/defconfig CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y · line 521
Quoted 2 lines · Otavio Salvador
meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1
-# 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.

Quoted 8 lines

Quoted 2 lines
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

Quoted 10 lines

Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Koen Kooi

2011-06-03 06:40 UTC #7 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven:

Quoted 20 lines · Richard Purdie

Quoted 19 lines · Otavio Salvador
Quoted 17 lines · Phil Blundell
Quoted 10 lines · Otavio Salvador
meta/recipes-core/busybox/busybox-1.18.4/defconfig CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y · line 521
Quoted 2 lines
meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1
-# 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.

Quoted 8 lines

Quoted 5 lines
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.

Richard Purdie

2011-06-03 08:28 UTC #8 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Quoted 28 lines · Koen Kooi

Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven:
Quoted 26 lines · Richard Purdie
Quoted 24 lines · Otavio Salvador
Quoted 12 lines · Phil Blundell
Quoted 10 lines · Otavio Salvador
meta/recipes-core/busybox/busybox-1.18.4/defconfig CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y · line 521
Quoted 2 lines
meta/recipes-core/busybox/busybox-1.18.4/defconfig +1 -1
-# 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.
Quoted 5 lines
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.

Quoted 6 lines

Quoted 2 lines
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

Koen Kooi

2011-06-03 09:02 UTC #9 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven:

Quoted 29 lines · Koen Kooi

Quoted 28 lines
Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven:
Quoted 26 lines · Richard Purdie
Quoted 24 lines · Otavio Salvador
Quoted 12 lines · Phil Blundell
Quoted 10 lines · Otavio Salvador
Review
Quoted 2 lines
(quoted diff) +1 -1
-# 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.
Quoted 5 lines
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.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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

Richard Purdie

2011-06-03 09:54 UTC #10 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Quoted 38 lines · Koen Kooi

Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven:
Quoted 36 lines · Koen Kooi
Quoted 34 lines
Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven:
Quoted 20 lines · Richard Purdie
Quoted 19 lines · Otavio Salvador
Quoted 17 lines · Phil Blundell
Quoted 10 lines · Otavio Salvador
Review
Quoted 2 lines
(quoted diff) +1 -1
-# 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.
Quoted 8 lines
Quoted 5 lines
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.

Quoted 6 lines

Quoted 1 line
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

Koen Kooi

2011-06-03 10:45 UTC #11 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

Op 3 jun 2011, om 11:50 heeft Richard Purdie het volgende geschreven:

Quoted 39 lines · Koen Kooi

Quoted 38 lines
Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven:
Quoted 36 lines · Koen Kooi
Quoted 34 lines
Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven:
Quoted 20 lines · Richard Purdie
Quoted 19 lines · Otavio Salvador
Quoted 17 lines · Phil Blundell
Quoted 10 lines · Otavio Salvador
Review
Quoted 2 lines
(quoted diff) +1 -1
-# 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.
Quoted 8 lines
Quoted 5 lines
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.

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
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 :)

Phil Blundell

2011-06-03 10:00 UTC #12 lore raw

Re: [PATCH 1/3] busybox: enable mdev by default

In reply to Khem Raj

Quoted 2 lines · Khem Raj

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.

Otavio Salvador

author

2011-06-01 20:13 UTC #13 lore raw

PATCH 2/3 qmake_base.bbclass: fix lrelease/lupdate binary names

In reply to Otavio Salvador

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 <[email protected]>

---
 meta/classes/qmake_base.bbclass |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

meta/classes/qmake_base.bbclass +5 -0

index a054efd..165d689 100644
@@ -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"

Signature · 1 line

1.7.2.5

Paul Eggleton

Acked-by on v1 2/3

2011-06-02 16:55 UTC #14 lore raw

Re: [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names

Quoted 23 lines · 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 <[email protected]>
---
 meta/classes/qmake_base.bbclass |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/meta/classes/qmake_base.bbclass index a054efd..165d689 100644
meta/classes/qmake_base.bbclass +5 -0
@@ -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

Quoted 5 lines

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 <[email protected]>

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Richard Purdie

Applied

2011-06-02 17:30 UTC #15 lore raw

Re: [PATCH 2/3] qmake_base.bbclass: fix lrelease/lupdate binary names

Quoted 18 lines · Paul Eggleton

Quoted 17 lines · 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 <[email protected]>
---
 meta/classes/qmake_base.bbclass |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/meta/classes/qmake_base.bbclass index a054efd..165d689 100644
meta/classes/qmake_base.bbclass +0 -0
@@ -92,6 +92,11 @@ qmake_base_do_configure() {
 		bbnote "qmake prevar substitution: ${EXTRA_QMAKEVARS_PRE}"
 	fi
 

Quoted 13 lines

Quoted 11 lines
meta/classes/qmake_base.bbclass +5 -0
+	# 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 <[email protected]>

Merged to master, thanks.

Richard

Otavio Salvador

author

2011-06-01 20:20 UTC #16 lore raw

PATCH 3/3 gnutls: link against 'dl' library

In reply to Otavio Salvador

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 <[email protected]>

---
 meta/recipes-support/gnutls/gnutls.inc       |    4 +++-
 meta/recipes-support/gnutls/gnutls_2.12.5.bb |    2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

meta/recipes-support/gnutls/gnutls.inc +3 -1

index 9f8d81b..9452190 100644
@@ -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.*"

meta/recipes-support/gnutls/gnutls_2.12.5.bb +1 -1

index b27a065..9d3f5ab 100644
@@ -1,6 +1,6 @@
 require gnutls.inc
 
-PR = "r0"
+PR = "${INC_PR}.0"
 
 SRC_URI += "file://gnutls-openssl.patch \
             file://configure-fix.patch"

Signature · 1 line

1.7.2.5

Phil Blundell

2011-06-01 20:36 UTC #17 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 1 line · Otavio Salvador

+export LDFLAGS += "-ldl"

The configure script ought to be figuring this out for itself. Do you know why that isn't working?

Otavio Salvador

author

2011-06-01 20:42 UTC #18 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 5 lines · Phil Blundell

Quoted 1 line · Otavio Salvador
+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?

Signature · 3 lines

Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Phil Blundell

2011-06-01 20:56 UTC #19 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 10 lines · Otavio Salvador

Quoted 5 lines · Phil Blundell
Quoted 1 line · Otavio Salvador
+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.

Otavio Salvador

author

2011-06-01 21:03 UTC #20 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 11 lines · Phil Blundell

Quoted 1 line · Otavio Salvador
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

Signature · 3 lines

Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Saul Wold

2011-06-01 21:47 UTC #21 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 13 lines · Otavio Salvador

Quoted 11 lines · Phil Blundell
Quoted 1 line · Otavio Salvador
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.

Quoted 9 lines

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!

Martin Jansa

2011-06-01 21:58 UTC #22 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 18 lines · Saul Wold

Quoted 17 lines · Otavio Salvador
Quoted 11 lines · Phil Blundell
Quoted 1 line · Otavio Salvador
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:

Quoted 8 lines

Quoted 5 lines
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

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Saul Wold

2011-06-01 22:22 UTC #23 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 36 lines · Martin Jansa

Quoted 18 lines · Saul Wold
Quoted 17 lines · Otavio Salvador
Quoted 11 lines · Phil Blundell
Quoted 1 line · Otavio Salvador
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:
Quoted 8 lines
Quoted 5 lines
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
(quoted diff) +0 -3
-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

Quoted 3 lines

/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!

Quoted 7 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Martin Jansa

2011-06-02 06:34 UTC #24 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Quoted 50 lines · Saul Wold

Quoted 36 lines · Martin Jansa
Quoted 18 lines · Saul Wold
Quoted 17 lines · Otavio Salvador
Quoted 11 lines · Phil Blundell
Quoted 1 line · Otavio Salvador
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:
Quoted 8 lines
Quoted 5 lines
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
(quoted diff) +0 -3
-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
Quoted 3 lines
/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
(quoted diff) +0 -3
-feliminate-unused-debug-types 
-I/builds/world/tmp/sysroots/qemux86/usr/include -Wl,-O1 
-Wl,--as-needed conftest.c  -ldl >&5

Quoted 4 lines

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,

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Koen Kooi

2011-06-02 09:33 UTC #25 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

Op 2 jun 2011, om 08:31 heeft Martin Jansa het volgende geschreven:

Quoted 58 lines · Saul Wold

Quoted 50 lines · Martin Jansa
Quoted 36 lines · Saul Wold
Quoted 18 lines · Otavio Salvador
Quoted 17 lines · Phil Blundell
Quoted 11 lines · Otavio Salvador
Quoted 1 line
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:
Quoted 8 lines
Quoted 5 lines
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
(quoted diff) +0 -3
-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
Quoted 3 lines
/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
(quoted diff) +0 -3
-feliminate-unused-debug-types 
-I/builds/world/tmp/sysroots/qemux86/usr/include -Wl,-O1 
-Wl,--as-needed conftest.c  -ldl >&5
Quoted 4 lines
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?

Quoted 4 lines

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

Richard Purdie

2011-06-02 09:42 UTC #26 lore raw

Re: [PATCH 3/3] gnutls: link against 'dl' library

In reply to Martin Jansa

Quoted 17 lines · Martin Jansa

what do you have in configlog for LIBDL?
here it's all empty
LIBDL=''
LIBDL_PREFIX=''
LTLIBDL=''
if I add
(quoted diff) +2 -0
+             --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'

Quoted 7 lines

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

Martin Jansa

2011-06-02 11:03 UTC #27 lore raw

PATCH 1/1 gnutls: add --with-libdl-prefix and --with-libpthread-prefix

Signed-off-by Martin Jansa <[email protected]>

---
 meta/recipes-support/gnutls/gnutls.inc |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

meta/recipes-support/gnutls/gnutls.inc +2 -0

index 9f8d81b..03aed6a 100644
@@ -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() {

Signature · 1 line

1.7.5.3

Richard Purdie

Applied

2011-06-02 13:56 UTC #28 lore raw

Re: [PATCH] gnutls: add --with-libdl-prefix and --with-libpthread-prefix

Quoted 10 lines · Martin Jansa

Signed-off-by Martin Jansa <[email protected]>
---
 meta/recipes-support/gnutls/gnutls.inc |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
meta/recipes-support/gnutls/gnutls.inc +0 -0
index 9f8d81b..03aed6a 100644

meta/recipes-support/gnutls/gnutls.inc inherit autotools binconfig pkgconfig gettext · line 29

Quoted 8 lines

meta/recipes-support/gnutls/gnutls.inc +2 -0

@@ -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