date:20170612

Re: [oe] [meta-oe][PATCH] hiredis: Add recipe

2017-06-12 Thread Andrea Galbusera

On Mon, Jun 12, 2017 at 8:36 PM, Marian Pritsak 
wrote:

> Hiredis is a C client library for Redis database.
> Hiredis does not use autotools, but plane Makefile instead,
> so few changes had to be made, including removing hard coded
> compiler, setting INSTALL to 'cp -r' to to avoid host user
> comtamination QA issue, and setting PREFIX to ${prefix} instead of
> default /usr/local.
>
> Signed-off-by: Marian Pritsak 
> ---
>  .../0001-Makefile-remove-hardcoding-of-CC.patch| 32
> ++
>  meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb | 21 ++
>  2 files changed, 53 insertions(+)
>  create mode 100644 meta-oe/recipes-extended/hiredis/files/0001-Makefile-
> remove-hardcoding-of-CC.patch
>  create mode 100644 meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb
>
> diff --git 
> a/meta-oe/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch
> b/meta-oe/recipes-extended/hiredis/files/0001-Makefile-
> remove-hardcoding-of-CC.patch
> new file mode 100644
> index 000..fef2bc7
> --- /dev/null
> +++ b/meta-oe/recipes-extended/hiredis/files/0001-Makefile-
> remove-hardcoding-of-CC.patch
> @@ -0,0 +1,32 @@
> +From d13b918a3ff8b0ebfd1e7b18b198b4b45841d720 Mon Sep 17 00:00:00 2001
> +From: Andrea Galbusera 
> +Date: Fri, 31 Jul 2015 16:42:08 +0200
> +Subject: [PATCH] Makefile: remove hardcoding of CC
> +
> +* upgrade previous patch to avoid wiping CFLAGS. This fixes build on arm
> +platforms which previously caused and issue due to -fPIC being lost
> +
> +Signed-off-by: Andrea Galbusera 
> +---
> + Makefile | 5 -
> + 1 file changed, 5 deletions(-)
> +
> +diff --git a/Makefile b/Makefile
> +index 8b0f0c2..66a4317 100644
> +--- a/Makefile
>  b/Makefile
> +@@ -34,11 +34,6 @@ define REDIS_TEST_CONFIG
> + endef
> + export REDIS_TEST_CONFIG
> +
> +-# Fallback to gcc when $CC is not in $PATH.
> +-CC:=$(shell sh -c 'type $(CC) >/dev/null 2>/dev/null && echo $(CC) ||
> echo gcc')
> +-OPTIMIZATION?=-O3
> +-WARNINGS=-Wall -W -Wstrict-prototypes -Wwrite-strings
> +-DEBUG?= -g -ggdb
> + REAL_CFLAGS=$(OPTIMIZATION) -fPIC $(CFLAGS) $(WARNINGS) $(DEBUG) $(ARCH)
> + REAL_LDFLAGS=$(LDFLAGS) $(ARCH)
> +
> +--
> +1.9.1
> +
> diff --git a/meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb
> b/meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb
> new file mode 100644
> index 000..96b86f9
> --- /dev/null
> +++ b/meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb
> @@ -0,0 +1,21 @@
> +DESCRIPTION = "Minimalistic C client library for Redis"
> +HOMEPAGE = "http://github.com/redis/hiredis;
> +LICENSE = "BSD-3-Clause"
> +SECTION = "libs"
> +DEPENDS = "redis"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d84d659a35c666d23233e54503aaea51"
> +SRC_URI = "git://github.com/redis/hiredis;protocol=git;rev=
> f58dd249d6ed47a7e835463c3b04722972281dbb \
> +   file://0001-Makefile-remove-hardcoding-of-CC.patch"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit autotools-brokensep pkgconfig
> +
> +# By default INSTALL variable in Makefile is equal to 'cp -a', which
> preserves
> +# ownership and causes host-user-contamination QA issue.
> +# And PREFIX defaults to /usr/local.
> +do_install_prepend() {
> +  export PREFIX=${prefix}
> +  export INSTALL='cp -r'
> +}
> --
> 2.7.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

A recipe for hiredis is already available from at least two other meta
layers as per [1], one of which does provide the same version as yours.
Don't know what the policy is here, but to me it seems worth a try talking
to those layers' maintainers and see if they agree to move the recipe to
meta-oe (at least meta-intel-iot-middleware is already listing meta-oe as a
dependency): it would help reducing the maintenance effort in the future.

[1]
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=hiredis
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt5] qtwebkit 5.8 build issues?

2017-06-12 Thread Denys Dmytriyenko

On Mon, Jun 12, 2017 at 03:04:24PM -0400, Denys Dmytriyenko wrote:
> On Wed, Apr 12, 2017 at 05:53:21PM -0700, Andre McCurdy wrote:
> > On Wed, Apr 12, 2017 at 5:11 PM, Andreas Oberritter
> >  wrote:
> > > On Wed, 12 Apr 2017 16:38:58 -0700
> > > Andre McCurdy  wrote:
> > >
> > >> On Wed, Apr 12, 2017 at 3:45 PM, Andreas Oberritter
> > >>  wrote:
> > >> > On Wed, 29 Mar 2017 19:06:14 -0400
> > >> > Denys Dmytriyenko  wrote:
> > >> >
> > >> >> On Sun, Mar 26, 2017 at 04:30:53PM -0400, Denys Dmytriyenko wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > I've been having the following build issues lately with qtwebkit 
> > >> >> > 5.8 from
> > >> >> > master:
> > >> >> >
> > >> >> > | make[2]: Entering directory 
> > >> >> > '/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/build/Source'
> > >> >> > | rm -f libQt5WebKit.so.5.8.0 libQt5WebKit.so libQt5WebKit.so.5 
> > >> >> > libQt5WebKit.so.5.8
> > >> >> > | linking ../lib/libQt5WebKit.so.5.8.0
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> > >> >> >  multiple definition of `__bss_start'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> > >> >> >  multiple definition of `__bss_start'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> > >> >> >  multiple definition of `_edata'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> > >> >> >  multiple definition of `_edata'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> > >> >> >  multiple definition of `_end'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> > >> >> >  multiple definition of `_end'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
> > >> >> >  multiple definition of `__bss_start'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
> > >> >> >  multiple definition of `_edata'
> > >> >> > | 
> > >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
> > >> >> >  multiple definition of `_end'
> > >> >> > | collect2: error: ld returned 1 exit status
> > >> >> > | Makefile.api:92: recipe for target '../lib/libQt5WebKit.so.5.8.0' 
> > >> >> > failed
> > >> >> > | make[2]: *** [../lib/libQt5WebKit.so.5.8.0] Error 1
> > >> >> > | make[2]: Leaving directory 
> > >> >> > '/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/build/Source'
> > >> >> > | Makefile.QtWebKit:44: recipe for target 
> > >> >> > 'sub-api-pri-make_first-ordered' failed
> > >> >> > | make[1]: *** [sub-api-pri-make_first-ordered] Error 2
> > >> >> >
> > >> >> > I believe I was able to build 5.8/master before, so I'm suspecting 
> > >> >> > recent
> > >> >> > binutils upgrade... But I can be wrong. Would really appreciate 
> > >> >> > some help
> > >> >> > here. Thanks.
> > >> >>
> > >> >> Anyone else see this?
> > >> >>
> > >> >
> > >> > I do. Have you been able to solve it in the meantime?
> > >>
> > >> Do you both have gold enabled?
> > >>
> > >>   
> > >> https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1653529
> > >
> > > I don't use the ld-is-gold flag, but gold gets built nevertheless. It's 
> > > just not
> > > the default linker. I guess qtwebkit forces its use. So the question 
> > > becomes whether
> > > I should set ld-is-gold or teach qtwebkit not to use gold, in order not 
> > > to mix both
> > > linkers.
> > 
> > Assuming qtwebkit has a configure option to explicitly enable/disable
> > gold, I'd say add a PACKAGECONFIG option.
> > 
> > In the short term keep the PACKAGECONFIG option disabled and in the
> > longer term (once qtwebkit builds successfully with gold enabled) set
> > the PACKAGECONFIG option based on the testing the distro feature.
> 
> Has there been any progress on this? Is anybody looking at adding this 
> PACKAGECONFIG flag?

Ok, patch is submitted. I don't believe there's a need for PACKAGECONFIG.

[oe] [meta-qt5][PATCH] qtbase: respect "ld-is-gold" DISTRO_FEATURES

2017-06-12 Thread Denys Dmytriyenko

From: Denys Dmytriyenko 

If not set explicitly, some modules like QtWebKit and QtQuick1 can fail:

| make[2]: Entering directory 
'/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/build/Source'
| rm -f libQt5WebKit.so.5.8.0 libQt5WebKit.so libQt5WebKit.so.5 
libQt5WebKit.so.5.8
| linking ../lib/libQt5WebKit.so.5.8.0
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
 multiple definition of `__bss_start'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
 multiple definition of `__bss_start'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
 multiple definition of `_edata'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
 multiple definition of `_edata'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
 multiple definition of `_end'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
 multiple definition of `_end'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
 multiple definition of `__bss_start'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
 multiple definition of `_edata'
| 
/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
 multiple definition of `_end'
| collect2: error: ld returned 1 exit status
| Makefile.api:92: recipe for target '../lib/libQt5WebKit.so.5.8.0' failed
| make[2]: *** [../lib/libQt5WebKit.so.5.8.0] Error 1
| make[2]: Leaving directory 
'/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/build/Source'
| Makefile.QtWebKit:44: recipe for target 'sub-api-pri-make_first-ordered' 
failed
| make[1]: *** [sub-api-pri-make_first-ordered] Error 2

Signed-off-by: Denys Dmytriyenko 
---
 recipes-qt/qt5/qtbase_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-qt/qt5/qtbase_git.bb b/recipes-qt/qt5/qtbase_git.bb
index 27d0de1..5cfbcfa 100644
--- a/recipes-qt/qt5/qtbase_git.bb
+++ b/recipes-qt/qt5/qtbase_git.bb
@@ -126,6 +126,7 @@ PACKAGECONFIG[libinput] = "-libinput,-no-libinput,libinput"
 PACKAGECONFIG[journald] = "-journald,-no-journald,systemd"
 
 QT_CONFIG_FLAGS += " \
+${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', '-use-gold-linker', 
'-no-use-gold-linker', d)} \
 -shared \
 -silent \
 -no-pch \
-- 
2.7.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt5] qtwebkit 5.8 build issues?

2017-06-12 Thread Denys Dmytriyenko

On Wed, Apr 12, 2017 at 05:53:21PM -0700, Andre McCurdy wrote:
> On Wed, Apr 12, 2017 at 5:11 PM, Andreas Oberritter
>  wrote:
> > On Wed, 12 Apr 2017 16:38:58 -0700
> > Andre McCurdy  wrote:
> >
> >> On Wed, Apr 12, 2017 at 3:45 PM, Andreas Oberritter
> >>  wrote:
> >> > On Wed, 29 Mar 2017 19:06:14 -0400
> >> > Denys Dmytriyenko  wrote:
> >> >
> >> >> On Sun, Mar 26, 2017 at 04:30:53PM -0400, Denys Dmytriyenko wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I've been having the following build issues lately with qtwebkit 5.8 
> >> >> > from
> >> >> > master:
> >> >> >
> >> >> > | make[2]: Entering directory 
> >> >> > '/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/build/Source'
> >> >> > | rm -f libQt5WebKit.so.5.8.0 libQt5WebKit.so libQt5WebKit.so.5 
> >> >> > libQt5WebKit.so.5.8
> >> >> > | linking ../lib/libQt5WebKit.so.5.8.0
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> >> >> >  multiple definition of `__bss_start'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> >> >> >  multiple definition of `__bss_start'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> >> >> >  multiple definition of `_edata'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> >> >> >  multiple definition of `_edata'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> >> >> >  multiple definition of `_end'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Core.so:(*IND*+0x0):
> >> >> >  multiple definition of `_end'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
> >> >> >  multiple definition of `__bss_start'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
> >> >> >  multiple definition of `_edata'
> >> >> > | 
> >> >> > /OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/recipe-sysroot/usr/lib/libQt5Gui.so:(*IND*+0x0):
> >> >> >  multiple definition of `_end'
> >> >> > | collect2: error: ld returned 1 exit status
> >> >> > | Makefile.api:92: recipe for target '../lib/libQt5WebKit.so.5.8.0' 
> >> >> > failed
> >> >> > | make[2]: *** [../lib/libQt5WebKit.so.5.8.0] Error 1
> >> >> > | make[2]: Leaving directory 
> >> >> > '/OE/master/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtwebkit/5.8.0+gitAUTOINC+74ac5b0f34-r0/build/Source'
> >> >> > | Makefile.QtWebKit:44: recipe for target 
> >> >> > 'sub-api-pri-make_first-ordered' failed
> >> >> > | make[1]: *** [sub-api-pri-make_first-ordered] Error 2
> >> >> >
> >> >> > I believe I was able to build 5.8/master before, so I'm suspecting 
> >> >> > recent
> >> >> > binutils upgrade... But I can be wrong. Would really appreciate some 
> >> >> > help
> >> >> > here. Thanks.
> >> >>
> >> >> Anyone else see this?
> >> >>
> >> >
> >> > I do. Have you been able to solve it in the meantime?
> >>
> >> Do you both have gold enabled?
> >>
> >>   
> >> https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1653529
> >
> > I don't use the ld-is-gold flag, but gold gets built nevertheless. It's 
> > just not
> > the default linker. I guess qtwebkit forces its use. So the question 
> > becomes whether
> > I should set ld-is-gold or teach qtwebkit not to use gold, in order not to 
> > mix both
> > linkers.
> 
> Assuming qtwebkit has a configure option to explicitly enable/disable
> gold, I'd say add a PACKAGECONFIG option.
> 
> In the short term keep the PACKAGECONFIG option disabled and in the
> longer term (once qtwebkit builds successfully with gold enabled) set
> the PACKAGECONFIG option based on the testing the distro feature.

Has there been any progress on this? Is anybody looking at adding this 
PACKAGECONFIG flag?

-- 
Denys
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-multimedia][PATCH] libdc1394: Add X11 and opengl deps if distro has them in policy

2017-06-12 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb 
b/meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb
index 8318385b6..8a9e9a1d7 100755
--- a/meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb
+++ b/meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb
@@ -5,7 +5,10 @@ LICENSE = "LGPL-2.0"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c848e78d9a4a5cc69906178e4d6fbd64"
 
 # libsdl to provide sdl.m4 with AM_PATH_SDL
-DEPENDS += "libusb1 libraw1394 libsdl"
+DEPENDS += "libusb1 libraw1394 libsdl \
+${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv 
virtual/libx11', '', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl 
libglu', '', d)} \
+"
 
 PV = "2.2.5+gitr${SRCPV}"
 
-- 
2.13.1

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe] [PATCH] dos2unix: add recipe

2017-06-12 Thread Denys Dmytriyenko

FWIW, Mentor layer has a tofrodos recipe that does the same... Maybe Chris can 
submit that one here? :)

-- 
Denys


On Mon, Jun 12, 2017 at 08:53:55PM +0200, Martin Jansa wrote:
> Please pass LDFLAGS to resolve following QA warning:
> 
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> dos2unix/7.3.4-r0/packages-split/dos2unix/usr/bin/dos2unix'
> No GNU_HASH in the elf binary:
> 'dos2unix/7.3.4-r0/packages-split/dos2unix/usr/bin/unix2dos' [ldflags]
> 
> On Sun, Jun 11, 2017 at 2:54 PM,  wrote:
> 
> > From: Ming Liu 
> >
> > The Dos2unix package includes utilities dos2unix and unix2dos to
> > convert plain text files in DOS or Mac format to Unix format and
> > vice versa.
> >
> > Signed-off-by: Ming Liu 
> > ---
> >  meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb | 34
> > ++
> >  1 file changed, 34 insertions(+)
> >  create mode 100644 meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> >
> > diff --git a/meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> > b/meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> > new file mode 100644
> > index 000..f3d5173
> > --- /dev/null
> > +++ b/meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> > @@ -0,0 +1,34 @@
> > +SUMMARY = "Convert text file line endings between CRLF and LF"
> > +DESCRIPTION = "The Dos2unix package includes utilities dos2unix and \
> > +unix2dos to convert plain text files in DOS or Mac format to Unix \
> > +format and vice versa."
> > +HOMEPAGE = "http://waterlan.home.xs4all.nl/dos2unix.html;
> > +SECTION = "support"
> > +
> > +LICENSE = "BSD-2-Clause"
> > +LIC_FILES_CHKSUM = "file://COPYING.txt;md5=1b78fca784db24f4a40e30b300787f
> > 3f"
> > +
> > +SRC_URI = "git://git.code.sf.net/p/dos2unix/dos2unix"
> > +
> > +# Release 7.3.4
> > +SRCREV = "8381ba4e1c4cd5ce98ebd9c24726d51cb203cde0"
> > +
> > +S = "${WORKDIR}/git/dos2unix"
> > +
> > +inherit gettext perlnative
> > +
> > +# The dos2unix NLS relies on po4a-native, while po4a recipe is
> > +# provided by meta-perl layer, so make it optional here, you
> > +# need have meta-perl in bblayers.conf before enabling nls in
> > +# PACKAGECONFIG.
> > +PACKAGECONFIG ??= ""
> > +PACKAGECONFIG[nls] = "ENABLE_NLS=1,ENABLE_NLS=,po4a-native"
> > +
> > +EXTRA_OEMAKE = "${PACKAGECONFIG_CONFARGS}"
> > +EXTRA_OEMAKE_class-native = "ENABLE_NLS="
> > +
> > +do_install () {
> > +oe_runmake DESTDIR="${D}${base_prefix}" install
> > +}
> > +
> > +BBCLASSEXTEND = "native nativesdk"
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe] [PATCH] dos2unix: add recipe

2017-06-12 Thread Martin Jansa

Please pass LDFLAGS to resolve following QA warning:

ERROR: QA Issue: No GNU_HASH in the elf binary:
dos2unix/7.3.4-r0/packages-split/dos2unix/usr/bin/dos2unix'
No GNU_HASH in the elf binary:
'dos2unix/7.3.4-r0/packages-split/dos2unix/usr/bin/unix2dos' [ldflags]

On Sun, Jun 11, 2017 at 2:54 PM,  wrote:

> From: Ming Liu 
>
> The Dos2unix package includes utilities dos2unix and unix2dos to
> convert plain text files in DOS or Mac format to Unix format and
> vice versa.
>
> Signed-off-by: Ming Liu 
> ---
>  meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb | 34
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
>
> diff --git a/meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> b/meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> new file mode 100644
> index 000..f3d5173
> --- /dev/null
> +++ b/meta-oe/recipes-support/dos2unix/dos2unix_7.3.4.bb
> @@ -0,0 +1,34 @@
> +SUMMARY = "Convert text file line endings between CRLF and LF"
> +DESCRIPTION = "The Dos2unix package includes utilities dos2unix and \
> +unix2dos to convert plain text files in DOS or Mac format to Unix \
> +format and vice versa."
> +HOMEPAGE = "http://waterlan.home.xs4all.nl/dos2unix.html;
> +SECTION = "support"
> +
> +LICENSE = "BSD-2-Clause"
> +LIC_FILES_CHKSUM = "file://COPYING.txt;md5=1b78fca784db24f4a40e30b300787f
> 3f"
> +
> +SRC_URI = "git://git.code.sf.net/p/dos2unix/dos2unix"
> +
> +# Release 7.3.4
> +SRCREV = "8381ba4e1c4cd5ce98ebd9c24726d51cb203cde0"
> +
> +S = "${WORKDIR}/git/dos2unix"
> +
> +inherit gettext perlnative
> +
> +# The dos2unix NLS relies on po4a-native, while po4a recipe is
> +# provided by meta-perl layer, so make it optional here, you
> +# need have meta-perl in bblayers.conf before enabling nls in
> +# PACKAGECONFIG.
> +PACKAGECONFIG ??= ""
> +PACKAGECONFIG[nls] = "ENABLE_NLS=1,ENABLE_NLS=,po4a-native"
> +
> +EXTRA_OEMAKE = "${PACKAGECONFIG_CONFARGS}"
> +EXTRA_OEMAKE_class-native = "ENABLE_NLS="
> +
> +do_install () {
> +oe_runmake DESTDIR="${D}${base_prefix}" install
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.7.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

2017-06-12 Thread Khem Raj

On Mon, Jun 12, 2017 at 11:23 AM, Peter Kjellerstedt
 wrote:
> This looks great, except for one thing. What about external toolchains?
>
> We use Poky's compiler when building for ARM, but when building for
> MIPS we need to use our own, which is based on gcc 4.7.2 and not
> likely to be updated. With the suggested changes to security_flags.inc
> we will no longer be able to build with hardening enabled for MIPS...
>
> Regarding your changes:
> * Wouldn't it be better to define GCCPIE as:
> GCCPIE ??= ""
>   in meta/recipes-devtools/gcc/gcc-configure-common.inc and as:
> GCCPIE ?= "--enable-default-pie"
>   in meta/conf/distro/include/security_flags.inc? That way it is easy
>   to disable PIE by setting GCCPIE = "" in local.conf even if other
>   hardenings are enabled by including security_flags.inc.

that seems a fine idea, I will make this change locally.

> * It is probably a bad idea to change the definition of
>   SECURITY_NO_PIE_CFLAGS to:
> SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_CFLAGS}"
>   since it is most likely used to define SECURITY_CFLAGS in other
>   existing layers via the typical:
> SECURITY_CFLAGS_pn-foo = "${SECURITY_NO_PIE_CFLAGS}"
>   and you will then end up with a circular definition...
>
> For backwards compatibility it might be an idea to do the following
> in security_flags.inc:
>
> GCCPIE ?= "--enable-default-pie"
>
> # SECURITY_PIE_CFLAGS is used to maintain backwards compatibility for
> # the definitions of SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS after
> # the introduction of GCCPIE.
> SECURITY_PIE_CFLAGS ?= "${@'' if '${GCCPIE}' else '-pie -fpie'}"
> SECURITY_CFLAGS ?= "-fstack-protector-strong ${SECURITY_PIE_CFLAGS} 
> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} 
> ${SECURITY_STRINGFORMAT}"
>
> That way the SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS variables
> would keep their old values unless GCCPIE is set to something, which
> it is by default.

seems good yes, I will have run into this error once I plug in meta-oe
but was still building oe-core world.

>
> Enabling hardening but without PIE would then become:
>
> GCCPIE = ""
> SECURITY_PIE_CFLAGS = ""
>

agreed.

> //Peter
>
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: den 12 juni 2017 16:47
>> To: Patrick Ohly 
>> Cc: Peter Kjellerstedt ; openembedded-
>> de...@lists.openembedded.org
>> Subject: Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH
>> 1/3] meson: update Meson devtool to 0.40.1)
>>
>> Patrick
>>
>> I have a patchset that is redoing the PIE hardening with using some
>> help from gcc configuration itself. with this patch almost all of the
>> NOPIE entries in secuity.inc are fixed and we get gcc to take care of
>> -pie passing to compiler and linker when needed
>>
>> This patches are done after gcc7 recipes so I will propose them after
>> gcc7 but if you are interested here is the branch
>>
>> Top 6 patches are what you want from
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master
>>
>>
>> On Mon, Jun 12, 2017 at 12:04 AM, Patrick Ohly 
>> wrote:
>> > On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
>> >> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
>> >> > On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
>> >> > >
>> >> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly
>> 
>> >> > > wrote:
>> >> > >
>> >> > > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt
>> wrote:
>> >> > > > My guess is that the problem stems from the fact that
>> >> > > security_flags.inc
>> >> > > > adds -pie (which is a linker flag) to SECURITY_CFLAGS
>> rather
>> >> > > than
>> >> > > > SECURITY_LDFLAGS...
>> >> > >
>> >> > > I think I've seen that cause problems elsewhere when the
>> >> > > CFLAGS came
>> >> > > after -shared, because then the compiler ended up trying
>> to
>> >> > > produce a
>> >> > > pie executable instead of a shared library.
>> >> > >
>> >> > > Perhaps we should finally address that in
>> security_flags.inc
>> >> > > instead of
>> >> > > working around it?
>> >> > >
>> >> > >
>> >> > > This patch is removing -pie from compiler and linker flags which
>> does
>> >> > > not result in intended behavior for executable when linked they
>> will
>> >> > > not be using -pie
>> >> >
>> >> > The patch had some syntax errors (fixed version below), but it had
>> the
>> >> > code which adds -pie to TARGET_LDFLAGS when it is in
>> SECURITY_CFLAGS, so
>> >> > conceptually the flag shouldn't get lost entirely.
>> >> >
>> >> > Are you saying that one cannot rely on TARGET_LDFLAGS being used
>> during
>> >> > linking?
>> >> >
>> >> > I've tested with m4, and it seems to work okay:
>> >> >
>> >> > $ grep -w

[oe] [meta-oe][PATCH] hiredis: Add recipe

2017-06-12 Thread Marian Pritsak

Hiredis is a C client library for Redis database.
Hiredis does not use autotools, but plane Makefile instead,
so few changes had to be made, including removing hard coded
compiler, setting INSTALL to 'cp -r' to to avoid host user
comtamination QA issue, and setting PREFIX to ${prefix} instead of
default /usr/local.

Signed-off-by: Marian Pritsak 
---
 .../0001-Makefile-remove-hardcoding-of-CC.patch| 32 ++
 meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb | 21 ++
 2 files changed, 53 insertions(+)
 create mode 100644 
meta-oe/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch
 create mode 100644 meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb

diff --git 
a/meta-oe/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch
 
b/meta-oe/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch
new file mode 100644
index 000..fef2bc7
--- /dev/null
+++ 
b/meta-oe/recipes-extended/hiredis/files/0001-Makefile-remove-hardcoding-of-CC.patch
@@ -0,0 +1,32 @@
+From d13b918a3ff8b0ebfd1e7b18b198b4b45841d720 Mon Sep 17 00:00:00 2001
+From: Andrea Galbusera 
+Date: Fri, 31 Jul 2015 16:42:08 +0200
+Subject: [PATCH] Makefile: remove hardcoding of CC
+
+* upgrade previous patch to avoid wiping CFLAGS. This fixes build on arm
+platforms which previously caused and issue due to -fPIC being lost
+
+Signed-off-by: Andrea Galbusera 
+---
+ Makefile | 5 -
+ 1 file changed, 5 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 8b0f0c2..66a4317 100644
+--- a/Makefile
 b/Makefile
+@@ -34,11 +34,6 @@ define REDIS_TEST_CONFIG
+ endef
+ export REDIS_TEST_CONFIG
+ 
+-# Fallback to gcc when $CC is not in $PATH.
+-CC:=$(shell sh -c 'type $(CC) >/dev/null 2>/dev/null && echo $(CC) || echo 
gcc')
+-OPTIMIZATION?=-O3
+-WARNINGS=-Wall -W -Wstrict-prototypes -Wwrite-strings
+-DEBUG?= -g -ggdb
+ REAL_CFLAGS=$(OPTIMIZATION) -fPIC $(CFLAGS) $(WARNINGS) $(DEBUG) $(ARCH)
+ REAL_LDFLAGS=$(LDFLAGS) $(ARCH)
+ 
+-- 
+1.9.1
+
diff --git a/meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb 
b/meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb
new file mode 100644
index 000..96b86f9
--- /dev/null
+++ b/meta-oe/recipes-extended/hiredis/hiredis_0.13.1.bb
@@ -0,0 +1,21 @@
+DESCRIPTION = "Minimalistic C client library for Redis"
+HOMEPAGE = "http://github.com/redis/hiredis;
+LICENSE = "BSD-3-Clause"
+SECTION = "libs"
+DEPENDS = "redis"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=d84d659a35c666d23233e54503aaea51"
+SRC_URI = 
"git://github.com/redis/hiredis;protocol=git;rev=f58dd249d6ed47a7e835463c3b04722972281dbb
 \
+   file://0001-Makefile-remove-hardcoding-of-CC.patch"
+
+S = "${WORKDIR}/git"
+
+inherit autotools-brokensep pkgconfig
+
+# By default INSTALL variable in Makefile is equal to 'cp -a', which preserves
+# ownership and causes host-user-contamination QA issue.
+# And PREFIX defaults to /usr/local.
+do_install_prepend() {
+  export PREFIX=${prefix}
+  export INSTALL='cp -r'
+}
-- 
2.7.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

2017-06-12 Thread Peter Kjellerstedt

This looks great, except for one thing. What about external toolchains?

We use Poky's compiler when building for ARM, but when building for 
MIPS we need to use our own, which is based on gcc 4.7.2 and not 
likely to be updated. With the suggested changes to security_flags.inc 
we will no longer be able to build with hardening enabled for MIPS...

Regarding your changes:
* Wouldn't it be better to define GCCPIE as:
GCCPIE ??= ""
  in meta/recipes-devtools/gcc/gcc-configure-common.inc and as:
GCCPIE ?= "--enable-default-pie"
  in meta/conf/distro/include/security_flags.inc? That way it is easy 
  to disable PIE by setting GCCPIE = "" in local.conf even if other 
  hardenings are enabled by including security_flags.inc.
* It is probably a bad idea to change the definition of 
  SECURITY_NO_PIE_CFLAGS to:
SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_CFLAGS}"
  since it is most likely used to define SECURITY_CFLAGS in other 
  existing layers via the typical:
SECURITY_CFLAGS_pn-foo = "${SECURITY_NO_PIE_CFLAGS}"
  and you will then end up with a circular definition...

For backwards compatibility it might be an idea to do the following 
in security_flags.inc:

GCCPIE ?= "--enable-default-pie"

# SECURITY_PIE_CFLAGS is used to maintain backwards compatibility for 
# the definitions of SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS after 
# the introduction of GCCPIE.
SECURITY_PIE_CFLAGS ?= "${@'' if '${GCCPIE}' else '-pie -fpie'}"
SECURITY_CFLAGS ?= "-fstack-protector-strong ${SECURITY_PIE_CFLAGS} 
${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} 
${SECURITY_STRINGFORMAT}"

That way the SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS variables 
would keep their old values unless GCCPIE is set to something, which 
it is by default.

Enabling hardening but without PIE would then become:

GCCPIE = ""
SECURITY_PIE_CFLAGS = ""

//Peter

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: den 12 juni 2017 16:47
> To: Patrick Ohly 
> Cc: Peter Kjellerstedt ; openembedded-
> de...@lists.openembedded.org
> Subject: Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH
> 1/3] meson: update Meson devtool to 0.40.1)
> 
> Patrick
> 
> I have a patchset that is redoing the PIE hardening with using some
> help from gcc configuration itself. with this patch almost all of the 
> NOPIE entries in secuity.inc are fixed and we get gcc to take care of 
> -pie passing to compiler and linker when needed
> 
> This patches are done after gcc7 recipes so I will propose them after
> gcc7 but if you are interested here is the branch
> 
> Top 6 patches are what you want from
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master
> 
> 
> On Mon, Jun 12, 2017 at 12:04 AM, Patrick Ohly 
> wrote:
> > On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
> >> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
> >> > On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> >> > >
> >> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly
> 
> >> > > wrote:
> >> > >
> >> > > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt
> wrote:
> >> > > > My guess is that the problem stems from the fact that
> >> > > security_flags.inc
> >> > > > adds -pie (which is a linker flag) to SECURITY_CFLAGS
> rather
> >> > > than
> >> > > > SECURITY_LDFLAGS...
> >> > >
> >> > > I think I've seen that cause problems elsewhere when the
> >> > > CFLAGS came
> >> > > after -shared, because then the compiler ended up trying
> to
> >> > > produce a
> >> > > pie executable instead of a shared library.
> >> > >
> >> > > Perhaps we should finally address that in
> security_flags.inc
> >> > > instead of
> >> > > working around it?
> >> > >
> >> > >
> >> > > This patch is removing -pie from compiler and linker flags which
> does
> >> > > not result in intended behavior for executable when linked they
> will
> >> > > not be using -pie
> >> >
> >> > The patch had some syntax errors (fixed version below), but it had
> the
> >> > code which adds -pie to TARGET_LDFLAGS when it is in
> SECURITY_CFLAGS, so
> >> > conceptually the flag shouldn't get lost entirely.
> >> >
> >> > Are you saying that one cannot rely on TARGET_LDFLAGS being used
> during
> >> > linking?
> >> >
> >> > I've tested with m4, and it seems to work okay:
> >> >
> >> > $ grep -w -e -pie tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-
> r0/temp/log.do_compile
> >> > x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -
> mfpmath=sse -msse4.2 --sysroot=/fast/build/refkit/intel-corei7-64/tmp-
> glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot   -O2 -
> pipe -g -feliminate-unused-debug-types -fdebug-prefix-
>

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

2017-06-12 Thread Khem Raj

Patrick

I have a patchset that is redoing the PIE hardening with using some help
from gcc configuration itself. with this patch almost all of the NOPIE entries
in secuity.inc are fixed and we get gcc to take care of -pie passing to compiler
and linker when needed

This patches are done after gcc7 recipes so I will propose them after gcc7 but
if you are interested here is the branch

Top 6 patches are what you want from
http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master


On Mon, Jun 12, 2017 at 12:04 AM, Patrick Ohly  wrote:
> On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
>> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
>> > On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
>> > >
>> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly 
>> > > wrote:
>> > >
>> > > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
>> > > > My guess is that the problem stems from the fact that
>> > > security_flags.inc
>> > > > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather
>> > > than
>> > > > SECURITY_LDFLAGS...
>> > >
>> > > I think I've seen that cause problems elsewhere when the
>> > > CFLAGS came
>> > > after -shared, because then the compiler ended up trying to
>> > > produce a
>> > > pie executable instead of a shared library.
>> > >
>> > > Perhaps we should finally address that in security_flags.inc
>> > > instead of
>> > > working around it?
>> > >
>> > >
>> > > This patch is removing -pie from compiler and linker flags which does
>> > > not result in intended behavior for executable when linked they will
>> > > not be using -pie
>> >
>> > The patch had some syntax errors (fixed version below), but it had the
>> > code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so
>> > conceptually the flag shouldn't get lost entirely.
>> >
>> > Are you saying that one cannot rely on TARGET_LDFLAGS being used during
>> > linking?
>> >
>> > I've tested with m4, and it seems to work okay:
>> >
>> > $ grep -w -e -pie 
>> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile
>> > x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse 
>> > -msse4.2 
>> > --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot
>> >-O2 -pipe -g -feliminate-unused-debug-types 
>> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0
>> >  
>> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native=
>> >  
>> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot=
>> >   -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat 
>> > -Wformat-security -Werror=format-security  -Wl,-O1 -Wl,--hash-style=gnu 
>> > -Wl,--as-needed -pie -fstack-protector-strong -Wl,-z,relro,-z,now -o m4 
>> > m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o 
>> > path.o symtab.o ../lib/libm4.a
>> >
>> > $ file 
>> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4
>> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4:
>> >  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
>> > linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
>> > BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped
>> >
>> > I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB
>> > executable" means "pie executable"?
>>
>> While I don't think my patch caused -pie to get lost, unfortunately I
>> now know that it still doesn't go into the right place in all cases. For
>> example, ncurses puts LDFLAGS after -shared, thus triggering the "main
>> undefined" error.
>>
>> The TOOLCHAIN_OPTIONS that Khem mentioned get appended directly after
>> the command, so that seems like a better place for -pie than LDFLAGS.
>> It's still a bit odd to pass a linker flag to all compiler invocations,
>> including those that do not link, but it might be a pragmatic solution
>> that is better than what we have now.
>>
>> However, my patch below now causes /usr/lib/libstdc++.a-gdb.py to be
>> built for gcc-runtime, which triggers an error:
>>
>> ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime:
>> Files/directories were installed but not shipped in any package:
>>   /usr/lib/libstdc++.a-gdb.py
>
> That's just a minor follow-up error. The real problem is that libstdc
> ++.so.6.0.22 was not getting built anymore. The expect .py file then is
> libstdc++.so.6.0.22-gdb.py.
>
> I'm still unsure about the root cause. Something seems to have gone
> wrong when building the toolchain, because gcc-runtime doesn't even have
> -pie in

[oe] [meta-oe][PATCHv2 2/2] debsums: New recipe

2017-06-12 Thread Tom Rini

A tool for verification of installed package files against MD5 checksums
debsums can verify the integrity of installed package files against MD5
checksums installed by the package, or generated from a .deb archive.

Signed-off-by: Tom Rini 
---
Changes in v2:
- Run oe-stylize.py over, check results and update.  Reword the -cron
  SUMMARY and DESCRIPTION.
---
 meta-oe/recipes-support/debsums/debsums_2.2.2.bb | 52 
 1 file changed, 52 insertions(+)
 create mode 100644 meta-oe/recipes-support/debsums/debsums_2.2.2.bb

diff --git a/meta-oe/recipes-support/debsums/debsums_2.2.2.bb 
b/meta-oe/recipes-support/debsums/debsums_2.2.2.bb
new file mode 100644
index ..41ebf87b2d98
--- /dev/null
+++ b/meta-oe/recipes-support/debsums/debsums_2.2.2.bb
@@ -0,0 +1,52 @@
+SUMMARY = "Miscellaneous utilities specific to Debian"
+SUMMARY_${PN}-cron = "Cron scripts to control automatic debsum checking"
+DESCRIPTION = "A tool for verification of installed package files against \
+MD5 checksums debsums can verify the integrity of installed package files \
+against MD5 checksums installed by the package, or generated from a .deb \
+archive."
+DESCRIPTION_${PN}-cron = "Cron scripts to control automatic system integrity \
+checking via debsums."
+SECTION = "base"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = 
"file://debian/copyright;md5=770d751553e6559e9eaefd2e11ccf7e9"
+
+SRC_URI = 
"http://snapshot.debian.org/archive/debian/20170530T212108Z/pool/main/d/debsums/debsums_2.2.2.tar.xz;
+SRC_URI[md5sum] = "82b0710855a7e5212d4358163a269e79"
+SRC_URI[sha256sum] = 
"aa61896f93a6bbfe0161c21dcd67529ae8e1ec8c3ccf244523c52c4ad8253d97"
+
+# the package is taken from snapshots.debian.org; that source is static and 
goes stale
+# so we check the latest upstream from a directory that does get updated
+UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/"
+
+do_install() {
+install -d ${D}/${sysconfdir}/cron.daily ${D}/${sysconfdir}/cron.weekly
+install -d ${D}/${sysconfdir}/cron.monthly ${D}${sbindir} ${D}${bindir}
+install -d ${D}${mandir}/man1 ${D}${mandir}/man8
+install -m 0755 debsums ${D}${bindir}/
+install -m 0755 rdebsums ${D}${bindir}/
+install -m 0755 debsums_init ${D}${sbindir}
+install -m 0644 man/debsums.1 ${D}${mandir}/man1/
+install -m 0644 man/rdebsums.1 ${D}${mandir}/man1/
+install -m 0644 man/debsums_init.8 ${D}${mandir}/man8/
+install -m 0644 debian/cron.daily \
+${D}/${sysconfdir}/cron.daily/debsums
+install -m 0644 debian/cron.weekly \
+${D}/${sysconfdir}/cron.weekly/debsums
+install -m 0644 debian/cron.monthly \
+${D}/${sysconfdir}/cron.monthly/debsums
+# Must exist, defaults to empty.
+touch ${D}/${sysconfdir}/debsums-ignore
+}
+
+PACKAGES =+ "${PN}-cron"
+
+RDEPENDS_${PN} = "dpkg dpkg-perl libfile-fnmatch-perl perl \
+  perl-module-constant perl-module-digest-md5 \
+  perl-module-errno perl-module-fcntl \
+  perl-module-file-basename perl-module-file-copy \
+  perl-module-file-find perl-module-file-glob \
+  perl-module-file-path perl-module-file-spec \
+  perl-module-file-temp perl-module-getopt-long \
+  perl-module-posix"
+
+FILES_${PN}-cron = "${sysconfdir}/cron.*"
-- 
1.9.1

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.9.0

2017-06-12 Thread Martin Jansa

On Fri, Jun 09, 2017 at 09:34:09AM +0300, Samuli Piippo wrote:
> * adapt QtWebEngine recipe to use GN instead of GYP
> * add QtRemoteObjects and QtWebView as a new Qt modules
> * update available QtBase configure arguments
> * remove obsolete patches
> * patch all .pc files to remove build paths
> * include generated QML cache files in packages
> * the patch "configure paths for target qmake properly" could not
>   be applied anymore and support must be done differently
> 
> * QtWebEngine now requires gcc-multilib to be installed on the host
>   system, because the host tools are built to the same bitness as
>   the target (arm -> x86, aarch64 -> x86-64)

Two more QA issues detected in last build:

count: 2issue: host-user-contaminated
qt5-creator: /qt5-creator/usr/lib/qt5/qtcreator/plugins/libIos.so is
owned by uid 3004, which is the same as the user running bitbake. This
may be due to host contamination [host-user-contaminated]
qtlocation-5.9.0+gitAUTOINC+888d351cb0_d45c177e8a: qtlocation:
/qtlocation-dev/usr/lib/cmake/Qt5Location/Qt5Location_GeoServiceProviderFactoryEsri.cmake
is owned by uid 3004, which is the same as the user running bitbake.
This may be due to host contamination [host-user-contaminated]

http://lists.openembedded.org/pipermail/openembedded-core/2017-June/137923.html

> 
> Signed-off-by: Samuli Piippo 
> ---
>  classes/qmake5_base.bbclass|   6 +-
>  recipes-qt/qt5/nativesdk-qtbase_git.bb |   7 +-
>  .../qt5/qt3d/0001-Allow-a-tools-only-build.patch   |  16 +++-
>  recipes-qt/qt5/qt3d_git.bb |   2 +-
>  recipes-qt/qt5/qt5-git.inc |   4 +-
>  recipes-qt/qt5/qt5.inc |  10 +-
>  recipes-qt/qt5/qtbase-native_git.bb|   9 +-
>  ...ake-Use-OE_QMAKE_PATH_EXTERNAL_HOST_BINS.patch} |   8 +-
>  ...le-Fix-pkgconfig-and-libtool-replacements.patch | 106 
> -
>  ...ump-path-length-from-256-to-512-character.patch |  41 
>  ...configure-paths-for-target-qmake-properly.patch |  75 ---
>  recipes-qt/qt5/qtbase_git.bb   |  13 +--
>  recipes-qt/qt5/qtcanvas3d_git.bb   |   2 +-
>  recipes-qt/qt5/qtcharts_git.bb |   2 +-
>  recipes-qt/qt5/qtconnectivity_git.bb   |   6 +-
>  recipes-qt/qt5/qtdatavis3d_git.bb  |   2 +-
>  .../qtdeclarative/0002-Fix-memory-leak-in-V4.patch |  44 -
>  ...leak-in-QQuickWindowPrivate-deliverTouchA.patch |  84 
>  recipes-qt/qt5/qtdeclarative_git.bb|   8 +-
>  recipes-qt/qt5/qtenginio_git.bb|   5 -
>  recipes-qt/qt5/qtgamepad_git.bb|   2 +-
>  recipes-qt/qt5/qtgraphicaleffects_git.bb   |   2 +-
>  recipes-qt/qt5/qtimageformats_git.bb   |   2 +-
>  .../0001-Make-mapbox-gl-build-configurable.patch   |  27 ++
>  recipes-qt/qt5/qtlocation_git.bb   |  13 ++-
>  recipes-qt/qt5/qtmultimedia_git.bb |   6 +-
>  recipes-qt/qt5/qtnetworkauth_git.bb|   3 +-
>  recipes-qt/qt5/qtquick1_git.bb |   2 +-
>  recipes-qt/qt5/qtquickcontrols2_git.bb |   6 +-
>  recipes-qt/qt5/qtquickcontrols_git.bb  |   7 +-
>  .../0001-Allow-a-tools-only-build.patch|  37 +++
>  recipes-qt/qt5/qtremoteobjects_git.bb  |  27 ++
>  recipes-qt/qt5/qtscript_git.bb |   2 +-
>  recipes-qt/qt5/qtscxml_git.bb  |   2 +-
>  recipes-qt/qt5/qtsensors_git.bb|   2 +-
>  recipes-qt/qt5/qtserialbus_git.bb  |   2 +-
>  recipes-qt/qt5/qtserialport_git.bb |   2 +-
>  recipes-qt/qt5/qtsvg_git.bb|   2 +-
>  ...t-help-fix-linking-of-dependent-libraries.patch |  29 --
>  recipes-qt/qt5/qttools_git.bb  |   8 +-
>  recipes-qt/qt5/qttranslations_git.bb   |   2 +-
>  recipes-qt/qt5/qtvirtualkeyboard_git.bb|   2 +-
>  recipes-qt/qt5/qtwayland_git.bb|   6 +-
>  recipes-qt/qt5/qtwebchannel_git.bb |   2 +-
>  .../0001-Force-host-toolchain-configuration.patch  |  69 ++
>  ...se.gypi-include-atomicops_internals_x86_g.patch |  24 -
>  ...um-workaround-for-too-long-.rps-file-name.patch |  42 
>  ...rf-Don-t-match-QMAKE_EXT_CPP-or-QMAKE_EXT.patch |  27 --
>  ...rf-Make-sure-we-only-use-the-file-name-to.patch |  26 -
>  ...s.prf-allow-build-for-linux-oe-g-platform.patch |  30 --
>  ...quickwebengineview_p_p.h-add-include-QCol.patch |  23 -
>  ...-dependency-to-QCoreApplication-translate.patch |  23 -
>  recipes-qt/qt5/qtwebengine_git.bb  |  54 +--
>  recipes-qt/qt5/qtwebkit-examples_git.bb|   2 +-
>  .../qtwebkit/0002-Remove-TEXTREL-tag-in-x86.patch  |  76 ---
>

[oe] State of bitbake world, Failed tasks 2017-06-08

2017-06-12 Thread Martin Jansa

http://www.openembedded.org/wiki/Bitbake_World_Status

== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!|Signatures !!colspan='14'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64||all   
||already-stripped  ||libdir||textrel   ||build-deps
||file-rdeps||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||ldflags   ||compile-host-path 
||  
|-
||2017-06-08||3 ||5 ||4 ||0 ||0 ||0 
||0 ||0 ||0 ||0 ||2 
||0 ||0 ||0 ||0 ||0 
||0 ||0 ||  
|}

== Failed tasks 2017-06-08 ==

INFO: jenkins-job.sh-1.8.21 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20170611_205435.log

=== common (2) ===
* 
meta-openembedded/meta-oe/recipes-devtools/librcf/librcf_2.2.0.0.bb:do_patch
* meta-openembedded/meta-oe/recipes-devtools/meson/meson_0.40.1.bb:do_patch

=== common-x86 (2) ===
* 
meta-openembedded/meta-oe/recipes-support/espeak/espeak_1.48.04.bb:do_compile
* meta-qt5/recipes-qt/qt5/qtwebengine_git.bb:do_compile

=== qemuarm (1) ===
* 
openembedded-core/meta/recipes-support/libunwind/libunwind_1.2.bb:do_compile

=== qemux86 (1) ===
* meta-openembedded/meta-oe/recipes-test/fwts/fwts_git.bb:do_compile

=== qemux86_64 (0) ===

=== Number of failed tasks (12) ===
{| class=wikitable
|-
|| qemuarm  || 3 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170608_030912.log/
 || http://errors.yoctoproject.org/Errors/Build/38783/
|-
|| qemux86  || 5 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemux86.20170608_030911.log/
 || http://errors.yoctoproject.org/Errors/Build/38784/
|-
|| qemux86_64   || 4 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemux86-64.20170608_054431.log/
 || http://errors.yoctoproject.org/Errors/Build/38792/
|}

=== PNBLACKLISTs (15) ===

=== QA issues (2) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||build-deps
|-
||0 ||compile-host-path
|-
||0 ||file-rdeps
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||ldflags
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||symlink-to-sysroot
|-
||0 ||textrel
|-
||0 ||unknown-configure-option
|-
||0 ||version-going-backwards
|-
||2 ||host-user-contaminated
|}



=== Incorrect PACKAGE_ARCH or sstate signatures (0) ===

Complete log: 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.signatures.20170608_052310.log/


* ERROR: Nothing PROVIDES 'qtwebengine' (but 
/home/jenkins/oe/world/shr-core/meta-qt5/recipes-qt/qt5/qtwebview_git.bb 
DEPENDS on or otherwise requires it)
* ERROR: qtwebengine was skipped: incompatible with machine qemuarm (not in 
COMPATIBLE_MACHINE)
* ERROR: Required build target 'meta-world-pkgdata' has no buildable 
providers.


PNBLACKLISTs:
openembedded-core/:
meta-browser:
recipes-browser/chromium/cef3_280796.bb:PNBLACKLIST[cef3] ?= "BROKEN: fails to 
build with gcc-6"
meta-openembedded:
meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.17.bb:PNBLACKLIST[lksctp-tools]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', "BROKEN: fails to 
link against sctp_connectx symbol", '', d)}"
meta-oe/recipes-connectivity/bluez/bluez-hcidump_2.5.bb:PNBLACKLIST[bluez-hcidump]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb:PNBLACKLIST[bluez4] ?= 
"${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb:PNBLACKLIST[gst-plugin-bluetooth]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-core/dbus/libdbus-c++_0.9.0.bb:PNBLACKLIST[libdbus-c++] ?= 
"Fails to build with RSS http://errors.yoctoproject.org/Errors/Details/130644/ 
- the recipe will be removed on 2017-09-01 unless the issue is fixed"
meta-oe/recipes-graphics/libsexy/libsexy_0.1.11.bb:PNBLACKLIST[libsexy] ?= 
"Fails to build with RSS http://errors.yoctoproject.org/Errors/Details/130607/ 
- the recipe will be removed on 2017-09-01 unless the issue is fixed"
meta-oe/recipes-graphics/xorg-driver/xf86-video-geode_2.11.16.bb:PNBLACKLIST[xf86-video-geode]
 ?= "BROKEN, fails to build - the recipe will be removed on 2017-09-01 unless 
the issue is fixed"

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

2017-06-12 Thread Patrick Ohly

On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
> > On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> > > 
> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly 
> > > wrote:
> > > 
> > > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> > > > My guess is that the problem stems from the fact that
> > > security_flags.inc
> > > > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather
> > > than
> > > > SECURITY_LDFLAGS...
> > > 
> > > I think I've seen that cause problems elsewhere when the
> > > CFLAGS came
> > > after -shared, because then the compiler ended up trying to
> > > produce a
> > > pie executable instead of a shared library.
> > > 
> > > Perhaps we should finally address that in security_flags.inc
> > > instead of
> > > working around it?
> > > 
> > > 
> > > This patch is removing -pie from compiler and linker flags which does
> > > not result in intended behavior for executable when linked they will
> > > not be using -pie
> > 
> > The patch had some syntax errors (fixed version below), but it had the
> > code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so
> > conceptually the flag shouldn't get lost entirely.
> > 
> > Are you saying that one cannot rely on TARGET_LDFLAGS being used during
> > linking?
> > 
> > I've tested with m4, and it seems to work okay:
> > 
> > $ grep -w -e -pie 
> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile
> > x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse 
> > -msse4.2 
> > --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot
> >-O2 -pipe -g -feliminate-unused-debug-types 
> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0
> >  
> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native=
> >  
> > -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot=
> >   -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat 
> > -Wformat-security -Werror=format-security  -Wl,-O1 -Wl,--hash-style=gnu 
> > -Wl,--as-needed -pie -fstack-protector-strong -Wl,-z,relro,-z,now -o m4 
> > m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o 
> > path.o symtab.o ../lib/libm4.a
> > 
> > $ file 
> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4
> >  
> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4:
> >  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
> > linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
> > BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped
> > 
> > I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB
> > executable" means "pie executable"?
> 
> While I don't think my patch caused -pie to get lost, unfortunately I
> now know that it still doesn't go into the right place in all cases. For
> example, ncurses puts LDFLAGS after -shared, thus triggering the "main
> undefined" error.
> 
> The TOOLCHAIN_OPTIONS that Khem mentioned get appended directly after
> the command, so that seems like a better place for -pie than LDFLAGS.
> It's still a bit odd to pass a linker flag to all compiler invocations,
> including those that do not link, but it might be a pragmatic solution
> that is better than what we have now.
> 
> However, my patch below now causes /usr/lib/libstdc++.a-gdb.py to be
> built for gcc-runtime, which triggers an error:
> 
> ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime:
> Files/directories were installed but not shipped in any package:
>   /usr/lib/libstdc++.a-gdb.py

That's just a minor follow-up error. The real problem is that libstdc
++.so.6.0.22 was not getting built anymore. The expect .py file then is
libstdc++.so.6.0.22-gdb.py.

I'm still unsure about the root cause. Something seems to have gone
wrong when building the toolchain, because gcc-runtime doesn't even have
-pie in the compiler flags. From log.do_configure:

checking whether the x86_64-refkit-linux-gcc  -m64 -march=corei7
-mtune=corei7 -mfpmath=sse -msse4.2
--sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/gcc-runtime/6.3.0-r0/recipe-sysroot
  -Wl,-z,relro,-z,now linker (x86_64-refkit-linux-ld 
--sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/gcc-runtime/6.3.0-r0/recipe-sysroot
  -Wl,-z,relro,-z,now   -m elf_x86_64) supports shared libraries... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... unsupported

Re: [oe] [meta-oe][PATCH] hiredis: Add recipe

2017-06-12 Thread Koen Kooi

Op 11-06-17 om 22:36 schreef Marian Pritsak:
> Hiredis is a C client library for Redis database.
> Hiredis does not use autotools, but plane Makefile instead,
> so few changes had to be made, including removing hard coded
> compiler, setting INSTALL to 'cp -r' to to avoid host user
> comtamination QA issue, and setting PREFIX to /usr instead of
> default /usr/local.
> 
> Signed-off-by: Marian Pritsak 

[..[

> +# By default INSTALL variable in Makefile is equal to 'cp -a', which 
> preserves
> +# ownership and causes host-user-contamination QA issue.
> +# And PREFIX defaults to /usr/local.
> +do_install_prepend() {
> +  export PREFIX=/usr
> +  export INSTALL='cp -r'
> +}

Don't hardcode '/usr', but use '${prefix}'


-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] hiredis: Add recipe

Re: [oe] [meta-qt5] qtwebkit 5.8 build issues?

[oe] [meta-qt5][PATCH] qtbase: respect "ld-is-gold" DISTRO_FEATURES

Re: [oe] [meta-qt5] qtwebkit 5.8 build issues?

[oe] [meta-multimedia][PATCH] libdc1394: Add X11 and opengl deps if distro has them in policy

Re: [oe] [meta-oe] [PATCH] dos2unix: add recipe

Re: [oe] [meta-oe] [PATCH] dos2unix: add recipe

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[oe] [meta-oe][PATCH] hiredis: Add recipe

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[oe] [meta-oe][PATCHv2 2/2] debsums: New recipe

Re: [oe] [meta-qt5][PATCH v4] Upgrade to Qt 5.9.0

[oe] State of bitbake world, Failed tasks 2017-06-08

Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

Re: [oe] [meta-oe][PATCH] hiredis: Add recipe

16 matches

Site Navigation

Mail list logo

Footer information