[oe] [meta-oe][PATCH v2] gflags: correct S and update library install directory

2017-03-20 Thread kai.kang
From: Kai Kang 

The current setting of S is not right for multilib. Remove the setting
and use the default value.

And library install directory is not right either. Pass ${libdir} to fix
the [installed-vs-shipped] QA issue:

| ERROR: gflags-2.2.0-r0 do_package: QA Issue: gflags: Files/directories
| were installed but not shipped in any package:
|   /usr/lib/libgflags.so
|   /usr/lib/libgflags_nothreads.so.2.2

Signed-off-by: Kai Kang 
---
 meta-oe/recipes-support/gflags/gflags_2.2.0.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb 
b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb
index b9188c3..77617ef 100644
--- a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb
+++ b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb
@@ -8,13 +8,12 @@ LIC_FILES_CHKSUM = 
"file://COPYING.txt;md5=c80d1a3b623f72bb85a4c75b556551df"
 SRC_URI = "https://github.com/gflags/gflags/archive/v${PV}.tar.gz;
 SRC_URI[md5sum] = "b99048d9ab82d8c56e876fb1456c285e"
 SRC_URI[sha256sum] = 
"466c36c6508a451734e4f4d76825cf9cd9b8716d2b70ef36479ae40f08271f88"
-S = "${WORKDIR}/${PN}-${PV}/"
 
 FILES_${PN}-dev += "${libdir}/cmake"
 
 inherit cmake
 
-EXTRA_OECMAKE="-DBUILD_SHARED_LIBS=ON -DREGISTER_INSTALL_PREFIX=OFF"
+EXTRA_OECMAKE="-DBUILD_SHARED_LIBS=ON -DREGISTER_INSTALL_PREFIX=OFF 
-DLIBRARY_INSTALL_DIR=${libdir}"
 
 PACKAGES =+ "${PN}-bash-completion"
 FILES_${PN}-bash-completion += "${bindir}/gflags_completions.sh"
-- 
2.10.1

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


[oe] [meta-oe][PATCH] gflags: remove setting of S

2017-03-20 Thread kai.kang
From: Kai Kang 

The current setting of S is not right for multilib. Remove the setting
and use the default value.

Signed-off-by: Kai Kang 
---
 meta-oe/recipes-support/gflags/gflags_2.2.0.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb 
b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb
index b9188c3..61a5972 100644
--- a/meta-oe/recipes-support/gflags/gflags_2.2.0.bb
+++ b/meta-oe/recipes-support/gflags/gflags_2.2.0.bb
@@ -8,7 +8,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING.txt;md5=c80d1a3b623f72bb85a4c75b556551df"
 SRC_URI = "https://github.com/gflags/gflags/archive/v${PV}.tar.gz;
 SRC_URI[md5sum] = "b99048d9ab82d8c56e876fb1456c285e"
 SRC_URI[sha256sum] = 
"466c36c6508a451734e4f4d76825cf9cd9b8716d2b70ef36479ae40f08271f88"
-S = "${WORKDIR}/${PN}-${PV}/"
 
 FILES_${PN}-dev += "${libdir}/cmake"
 
-- 
2.10.1

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


Re: [oe] OpenEmbedded Layer Index autobuild errors

2017-03-20 Thread Paul Eggleton
On Monday, 20 March 2017 11:46:06 AM NZDT Paul Eggleton wrote:
> On Monday, 20 March 2017 11:33:16 AM NZDT Paul Eggleton wrote:
> > On Monday, 20 March 2017 10:51:46 AM NZDT Max Krummenacher wrote:
> > > Am Sonntag, den 19.03.2017, 12:04 -0400 schrieb Daniel Dickinson:
> > > > On Sun, 19 Mar 2017 15:39:38 +0100
> > > > 
> > > > Gary Thomas  wrote:
> > > > > > With that change all tools which must be installed on the host
> > > > > > need
> > > > > > to be present, even if in your use case some of them might not be
> > > > > > used. Did you install the prerequisites?
> > > > > > http://www.yoctoproject.org/docs/2.2.1/ref-manual/ref-manual.html#
> > > > > > re
> > > > > > qu
> > > > > > ired-packages-for-the-ho st-dev
> > > > > > elopment-system
> > > > > 
> > > > > The real point is that it's not his host - it's the [remote]
> > > > > autobuilder tool for OpenEmbedded (IIRC)
> > > > 
> > > > Yes, thank you.  I'm not sure it's a full autobuilder or just parses
> > > > recipes for generating the web pages, but either way it's not my host,
> > > > it's an openembedded.org host.  Apparently I'm not good at explaining
> > > > that...
> > > 
> > > My bad, sorry.
> > > 
> > > And it looks like the host fails to update any of the layers, e.g. also
> > > openembedded-core:
> > > https://layers.openembedded.org/layerindex/layerupdate/323749/
> > > Adding Paul, as he maybe knows how to get those tools onto the server.
> > 
> > Ah yes - I think I may just take the cheap way out and clear HOSTTOOLS
> > when
> > parsing in the index - we're not doing any actual building, after all, so
> > we're not going to be calling any of these tools).
> 
> Well, perhaps I spoke too soon. We call gcc to check its version just when
> parsing, I suspect there may be others, so maybe the safest thing is to just
> install these tools. Things are rarely as simple as they first appear...

FYI I have merged a patch for this, just waiting for it to be applied in the 
OE infrastructure now.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-oe][PATCH V2 02/16] rapidjson: Update to 1.1.0 + git

2017-03-20 Thread Khem Raj
On Mon, Mar 20, 2017 at 2:30 PM, Andre McCurdy  wrote:
> On Sun, Mar 19, 2017 at 10:31 PM, Khem Raj  wrote:
>> Drop backports
>> Adjust the license checksums to match the changes to file especially
>>
>> https://github.com/miloyip/rapidjson/commit/b4b1a39937fbd168ef72ea477f90f626773d56fc
>>
>> Signed-off-by: Khem Raj 
>> ---
>>  .../Fix-gcc-strict-overflow-warning.patch  | 30 
>>  .../remove-march-native-from-CMAKE_CXX_FLAGS.patch | 41 
>> +-
>>  .../{rapidjson_1.0.2.bb => rapidjson_git.bb}   |  9 ++---
>>  3 files changed, 29 insertions(+), 51 deletions(-)
>>  delete mode 100644 
>> meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
>>  rename meta-oe/recipes-devtools/rapidjson/{rapidjson_1.0.2.bb => 
>> rapidjson_git.bb} (73%)
>>
>> diff --git 
>> a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
>>  
>> b/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
>> deleted file mode 100644
>> index 6ce3933ce..0
>> --- 
>> a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
>> +++ /dev/null
>> @@ -1,30 +0,0 @@
>> -From f5560d9557ee48fb79810180ddfd3ec386e2a7b5 Mon Sep 17 00:00:00 2001
>> -From: Milo Yip 
>> -Date: Wed, 2 Mar 2016 01:01:17 +0800
>> -Subject: [PATCH] Fix gcc strict-overflow warning
>> -
>> -Fix #566 #568
>> -
>> -Upstream-Status: Backport [Partial merge of upstream commit 928caf92e]
>> -
>> -Signed-off-by: Andre McCurdy 
>> 
>> - include/rapidjson/internal/dtoa.h | 2 +-
>> - 1 file changed, 1 insertion(+), 1 deletion(-)
>> -
>> -diff --git a/include/rapidjson/internal/dtoa.h 
>> b/include/rapidjson/internal/dtoa.h
>> -index 2d8d2e4..15571e1 100644
>>  a/include/rapidjson/internal/dtoa.h
>> -+++ b/include/rapidjson/internal/dtoa.h
>> -@@ -148,7 +148,7 @@ inline char* WriteExponent(int K, char* buffer) {
>> - inline char* Prettify(char* buffer, int length, int k) {
>> - const int kk = length + k;  // 10^(kk-1) <= v < 10^kk
>> -
>> --if (length <= kk && kk <= 21) {
>> -+if (0 <= k && kk <= 21) {
>> - // 1234e7 -> 1234000
>> - for (int i = length; i < kk; i++)
>> - buffer[i] = '0';
>> ---
>> -1.9.1
>> -
>> diff --git 
>> a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
>>  
>> b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
>> index 17164283c..cf3e16ea5 100644
>> --- 
>> a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
>> +++ 
>> b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
>> @@ -12,22 +12,29 @@ Signed-off-by: Andre McCurdy 
>>   CMakeLists.txt | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> -diff --git a/CMakeLists.txt b/CMakeLists.txt
>> -index 68139ba..cae7c9b 100644
>>  a/CMakeLists.txt
>> -+++ b/CMakeLists.txt
>> -@@ -26,9 +26,9 @@ if(RAPIDJSON_HAS_STDSTRING)
>> - endif()
>> +Index: git/CMakeLists.txt
>> +===
>> +--- git.orig/CMakeLists.txt
>>  git/CMakeLists.txt
>> +@@ -51,10 +51,10 @@ endif(CCACHE_FOUND)
>>
>>   if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
>> --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra")
>> -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
>> - elseif (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
>> --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra")
>> -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
>> - elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
>> - add_definitions(-D_CRT_SECURE_NO_WARNINGS=1)
>> - endif()
>> ---
>> -1.9.1
>> -
>> + if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "powerpc" OR 
>> ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "ppc64" OR ${CMAKE_SYSTEM_PROCESSOR} 
>> STREQUAL "ppc64le")
>> +-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native")
>> ++  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
>> + else()
>> +   #FIXME: x86 is -march=native, but doesn't mean every arch is this 
>> option. To keep original project's compatibility, I leave this except POWER.
>> +-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native")
>> ++  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
>> + endif()
>> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror")
>> + set(EXTRA_CXX_FLAGS -Weffc++ -Wswitch-default -Wfloat-equal 
>> -Wconversion -Wsign-conversion)
>> +@@ -84,7 +84,7 @@ elseif (CMAKE_CXX_COMPILER_ID MATCHES "C
>> +   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native")
>> + else()
>> +   #FIXME: x86 is -march=native, but doesn't mean every arch is this 
>> option. To keep original project's compatibility, I leave 

Re: [oe] [meta-oe][PATCH V2 02/16] rapidjson: Update to 1.1.0 + git

2017-03-20 Thread Andre McCurdy
On Sun, Mar 19, 2017 at 10:31 PM, Khem Raj  wrote:
> Drop backports
> Adjust the license checksums to match the changes to file especially
>
> https://github.com/miloyip/rapidjson/commit/b4b1a39937fbd168ef72ea477f90f626773d56fc
>
> Signed-off-by: Khem Raj 
> ---
>  .../Fix-gcc-strict-overflow-warning.patch  | 30 
>  .../remove-march-native-from-CMAKE_CXX_FLAGS.patch | 41 
> +-
>  .../{rapidjson_1.0.2.bb => rapidjson_git.bb}   |  9 ++---
>  3 files changed, 29 insertions(+), 51 deletions(-)
>  delete mode 100644 
> meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
>  rename meta-oe/recipes-devtools/rapidjson/{rapidjson_1.0.2.bb => 
> rapidjson_git.bb} (73%)
>
> diff --git 
> a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
>  
> b/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
> deleted file mode 100644
> index 6ce3933ce..0
> --- 
> a/meta-oe/recipes-devtools/rapidjson/rapidjson/Fix-gcc-strict-overflow-warning.patch
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -From f5560d9557ee48fb79810180ddfd3ec386e2a7b5 Mon Sep 17 00:00:00 2001
> -From: Milo Yip 
> -Date: Wed, 2 Mar 2016 01:01:17 +0800
> -Subject: [PATCH] Fix gcc strict-overflow warning
> -
> -Fix #566 #568
> -
> -Upstream-Status: Backport [Partial merge of upstream commit 928caf92e]
> -
> -Signed-off-by: Andre McCurdy 
> 
> - include/rapidjson/internal/dtoa.h | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/include/rapidjson/internal/dtoa.h 
> b/include/rapidjson/internal/dtoa.h
> -index 2d8d2e4..15571e1 100644
>  a/include/rapidjson/internal/dtoa.h
> -+++ b/include/rapidjson/internal/dtoa.h
> -@@ -148,7 +148,7 @@ inline char* WriteExponent(int K, char* buffer) {
> - inline char* Prettify(char* buffer, int length, int k) {
> - const int kk = length + k;  // 10^(kk-1) <= v < 10^kk
> -
> --if (length <= kk && kk <= 21) {
> -+if (0 <= k && kk <= 21) {
> - // 1234e7 -> 1234000
> - for (int i = length; i < kk; i++)
> - buffer[i] = '0';
> ---
> -1.9.1
> -
> diff --git 
> a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
>  
> b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
> index 17164283c..cf3e16ea5 100644
> --- 
> a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
> +++ 
> b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
> @@ -12,22 +12,29 @@ Signed-off-by: Andre McCurdy 
>   CMakeLists.txt | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> -diff --git a/CMakeLists.txt b/CMakeLists.txt
> -index 68139ba..cae7c9b 100644
>  a/CMakeLists.txt
> -+++ b/CMakeLists.txt
> -@@ -26,9 +26,9 @@ if(RAPIDJSON_HAS_STDSTRING)
> - endif()
> +Index: git/CMakeLists.txt
> +===
> +--- git.orig/CMakeLists.txt
>  git/CMakeLists.txt
> +@@ -51,10 +51,10 @@ endif(CCACHE_FOUND)
>
>   if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
> --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra")
> -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
> - elseif (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
> --set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -Wextra")
> -+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra")
> - elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
> - add_definitions(-D_CRT_SECURE_NO_WARNINGS=1)
> - endif()
> ---
> -1.9.1
> -
> + if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "powerpc" OR 
> ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "ppc64" OR ${CMAKE_SYSTEM_PROCESSOR} 
> STREQUAL "ppc64le")
> +-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native")
> ++  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
> + else()
> +   #FIXME: x86 is -march=native, but doesn't mean every arch is this 
> option. To keep original project's compatibility, I leave this except POWER.
> +-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native")
> ++  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
> + endif()
> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror")
> + set(EXTRA_CXX_FLAGS -Weffc++ -Wswitch-default -Wfloat-equal 
> -Wconversion -Wsign-conversion)
> +@@ -84,7 +84,7 @@ elseif (CMAKE_CXX_COMPILER_ID MATCHES "C
> +   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native")
> + else()
> +   #FIXME: x86 is -march=native, but doesn't mean every arch is this 
> option. To keep original project's compatibility, I leave this except POWER.
> +-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native")
> ++  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
> + endif()
> + set(CMAKE_CXX_FLAGS 

Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Robert P. J. Day
On Mon, 20 Mar 2017, Martin Jansa wrote:

> Yes, good enough for me to include the PNBLACKLIST removal in next bitbake 
> world run. thanks
>
> On Mon, Mar 20, 2017 at 4:27 PM, Robert P. J. Day  
> wrote:
>   On Mon, 20 Mar 2017, Martin Jansa wrote:
>
>   > Without "_pn-binutils".
>
>     so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask)
>   after setting:
>
>     DISTRO_FEATURES_append = " ld-is-gold"
>
>   then rebuilt accel-ppp and it succeeded. is that considered an
>   adequate test?

  i'll let you throw in that patch since you probably have a better
idea of what you want the commit msg to say.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-clang] llvm-config cross-compile improvements

2017-03-20 Thread Martin Kelly

On 03/20/2017 10:37 AM, Khem Raj wrote:

On Sat, Mar 18, 2017 at 8:29 PM, Martin Kelly  wrote:

Hi,

This patch series fixes a number of issues I hit when trying to use the
meta-clang llvm-config to cross-compile a project that uses CMake, calling
into llvm-config, to determine compile flags. With the series applied, the
cross compile successfully builds and runs. Please let me know if you have
any concerns or if there is something I missed, and I will fix it up.

The following changes since commit c9c74d269ba79abbc20919de96f1eb2b8a81edec:

  clang/compiler-rt: Fix nativesdk builds break compiler-rt dep for clang
(2017-03-16 22:54:02 -0700)

are available in the git repository at:

  https://github.com/surround-io/meta-clang

for you to fetch changes up to 7d294bc2548ade23b7d25761d73769e712617c51:




can you send a simple gh pull request please ?



Done; sorry, from the meta-clang readme, I thought it was asking for 
pull requests to go over openembedded-devel, but I'm happy with Github too.

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


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Martin Jansa
Yes, good enough for me to include the PNBLACKLIST removal in next bitbake
world run. thanks

On Mon, Mar 20, 2017 at 4:27 PM, Robert P. J. Day 
wrote:

> On Mon, 20 Mar 2017, Martin Jansa wrote:
>
> > Without "_pn-binutils".
>
>   so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask)
> after setting:
>
>   DISTRO_FEATURES_append = " ld-is-gold"
>
> then rebuilt accel-ppp and it succeeded. is that considered an
> adequate test?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-clang] llvm-config cross-compile improvements

2017-03-20 Thread Khem Raj
On Sat, Mar 18, 2017 at 8:29 PM, Martin Kelly  wrote:
> Hi,
>
> This patch series fixes a number of issues I hit when trying to use the
> meta-clang llvm-config to cross-compile a project that uses CMake, calling
> into llvm-config, to determine compile flags. With the series applied, the
> cross compile successfully builds and runs. Please let me know if you have
> any concerns or if there is something I missed, and I will fix it up.
>
> The following changes since commit c9c74d269ba79abbc20919de96f1eb2b8a81edec:
>
>   clang/compiler-rt: Fix nativesdk builds break compiler-rt dep for clang
> (2017-03-16 22:54:02 -0700)
>
> are available in the git repository at:
>
>   https://github.com/surround-io/meta-clang
>
> for you to fetch changes up to 7d294bc2548ade23b7d25761d73769e712617c51:
>


can you send a simple gh pull request please ?

>   clang: build for only target and host (2017-03-18 18:01:50 -0700)
>
> 
> Martin Kelly (5):
>   clang: correct spacing issue
>   clang: remove commented-out code
>   clang: fix the llvm-common wrapper
>   clang: build libLLVM.so
>   clang: build for only target and host
>
>  recipes-devtools/clang/clang.inc  |  5 -
>
> recipes-devtools/clang/clang/0004-llvm-allow-env-override-of-exe-path.patch
> | 36 ++
>  recipes-devtools/clang/clang_git.bb  | 52
> ++
>  recipes-devtools/clang/llvm-common/llvm-config  | 41
> +++
>  4 files changed, 96 insertions(+), 38 deletions(-)
>  create mode 100644
> recipes-devtools/clang/clang/0004-llvm-allow-env-override-of-exe-path.patch
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Robert P. J. Day
On Mon, 20 Mar 2017, Martin Jansa wrote:

> Without "_pn-binutils".

  so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask)
after setting:

  DISTRO_FEATURES_append = " ld-is-gold"

then rebuilt accel-ppp and it succeeded. is that considered an
adequate test?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


[oe] [meta-oe][PATCH v2 1/2] lvm2: libdevicemapper package needs udev rules and dmsetup

2017-03-20 Thread Patrick Ohly
Applications like kpartx and cryptsetup were broken by moving only
libdevicemapper itself into a separate package: as a result of that
change, lvm2 was not getting pulled into images anymore although
libdevicemapper depends on dmsetup and udev rules to be fully
functional.

For example, "kpartx -as" started to hang while waiting for the udev
rules to trigger, which is what creates the /dev/mapper/ entries for
the new partitions (see also
https://github.com/docker/docker/issues/22025#issuecomment-243943728).

Putting udev rules and dmsetup also into libdevicemapper is perhaps
counter-intuitive, but necessary to keep the package functioning. A
full lvm2 installation is guaranteed to pull them in, too, both
because of implicit library dependencies and (just to be sure) an
explicit RDEPENDS.

lvm2-native doesn't have packages, so this RDEPENDS must be limited to
the target case.

Signed-off-by: Patrick Ohly 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 3e79552..cfa74d4 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev"
+FILES_${PN} += "${libdir}/device-mapper/*.so"
 FILES_${PN}-scripts = " \
 ${sbindir}/blkdeactivate \
 ${sbindir}/fsadm \
 ${sbindir}/lvmconf \
 ${sbindir}/lvmdump \
 "
-FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+# Specified explicitly for the udev rules, just in case that it does not get 
picked
+# up automatically:
+RDEPENDS_${PN}_append_class-target = " libdevmapper"
+FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* 
${nonarch_base_libdir}/udev/rules.d"
 FILES_libdevmapper-dev = " \
 ${libdir}/libdevmapper.so \
 ${libdir}/pkgconfig/devmapper.pc \

base-commit: 6c584374a599f6f8d3607f20ecfc13a67ccf1da1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] [meta-oe][PATCH v2 2/2] lvm2: fix lvm2-native RRECOMMENDS problem

2017-03-20 Thread Patrick Ohly
lvm2-native doesn't have packages, so the RRECOMMENDS must be limited
to the target case. This fixes:

ERROR: Nothing RPROVIDES 'lvm2-native-scripts-native' (but 
virtual:native:.../meta-openembedded/meta-oe/recipes-support/lvm2/lvm2_2.02.166.bb
 RDEPENDS on or otherwise requires it)

Signed-off-by: Patrick Ohly 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index cfa74d4..d0be296 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -103,6 +103,6 @@ FILES_libdevmapper-dev = " \
 RDEPENDS_${PN}-scripts = "${PN} (= ${EXTENDPKGV}) bash"
 RDEPENDS_${PN} = " bash"
 RDEPENDS_libdevmapper-dev = "libdevmapper (= ${EXTENDPKGV})"
-RRECOMMENDS_${PN} = "${PN}-scripts (= ${EXTENDPKGV})"
+RRECOMMENDS_${PN}_class-target = "${PN}-scripts (= ${EXTENDPKGV})"
 
 CONFFILES_${PN} += "${sysconfdir}/lvm/lvm.conf"
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Robert P. J. Day
On Mon, 20 Mar 2017, Martin Jansa wrote:

> Without "_pn-binutils".
>
> On Mon, Mar 20, 2017 at 3:05 PM, Robert P. J. Day  
> wrote:
>   On Mon, 20 Mar 2017, Martin Jansa wrote:
>
>   > Yes, sending a patch is OK, but you might want to test it with gold
>   > enabled, most linking errors are usually reproducible only when gold
>   > is enabled.
>
>     just to be clear, need i add just this line to my local.conf?
>
>   DISTRO_FEATURES_append_pn-binutils = " ld-is-gold"

  ah, right, i forgot that it also affects a number of other recipes.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Martin Jansa
Without "_pn-binutils".

On Mon, Mar 20, 2017 at 3:05 PM, Robert P. J. Day 
wrote:

> On Mon, 20 Mar 2017, Martin Jansa wrote:
>
> > Yes, sending a patch is OK, but you might want to test it with gold
> > enabled, most linking errors are usually reproducible only when gold
> > is enabled.
>
>   just to be clear, need i add just this line to my local.conf?
>
> DISTRO_FEATURES_append_pn-binutils = " ld-is-gold"
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Robert P. J. Day
On Mon, 20 Mar 2017, Martin Jansa wrote:

> Yes, sending a patch is OK, but you might want to test it with gold
> enabled, most linking errors are usually reproducible only when gold
> is enabled.

  just to be clear, need i add just this line to my local.conf?

DISTRO_FEATURES_append_pn-binutils = " ld-is-gold"

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


[oe] [meta-oe][PATCH] lvm2: libdevicemapper package needs udev rules and dmsetup

2017-03-20 Thread Patrick Ohly
Applications like kpartx and cryptsetup were broken by moving only
libdevicemapper itself into a separate package: as a result of that
change, lvm2 was not getting pulled into images anymore although
libdevicemapper depends on dmsetup and udev rules to be fully
functional.

For example, "kpartx -as" started to hang while waiting for the udev
rules to trigger, which is what creates the /dev/mapper/ entries for
the new partitions (see also
https://github.com/docker/docker/issues/22025#issuecomment-243943728).

Putting udev rules and dmsetup also into libdevicemapper is perhaps
counter-intuitive, but necessary to keep the package functioning. A
full lvm2 installation is guaranteed to pull them in, too, both
because of implicit library dependencies and (just to be sure) an
explicit RDEPENDS.

Signed-off-by: Patrick Ohly 
---
 meta-oe/recipes-support/lvm2/lvm2.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc 
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 3e79552..c0fe755 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev"
+FILES_${PN} += "${libdir}/device-mapper/*.so"
 FILES_${PN}-scripts = " \
 ${sbindir}/blkdeactivate \
 ${sbindir}/fsadm \
 ${sbindir}/lvmconf \
 ${sbindir}/lvmdump \
 "
-FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+# Specified explicitly for the udev rules, just in case that it does not get 
picked
+# up automatically:
+RDEPENDS_${PN} += "libdevmapper"
+FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* 
${nonarch_base_libdir}/udev/rules.d"
 FILES_libdevmapper-dev = " \
 ${libdir}/libdevmapper.so \
 ${libdir}/pkgconfig/devmapper.pc \

base-commit: 6c584374a599f6f8d3607f20ecfc13a67ccf1da1
-- 
git-series 0.9.1
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Robert P. J. Day
On Mon, 20 Mar 2017, Martin Jansa wrote:

> Yes, sending a patch is OK, but you might want to test it with gold
> enabled, most linking errors are usually reproducible only when gold
> is enabled.

  okeley dokeley.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Martin Jansa
Yes, sending a patch is OK, but you might want to test it with gold
enabled, most linking errors are usually reproducible only when gold is
enabled.

On Mon, Mar 20, 2017 at 2:04 PM, Andreas Müller <
schnitzelt...@googlemail.com> wrote:

> On Mon, Mar 20, 2017 at 12:56 PM, Robert P. J. Day
>  wrote:
> >
> >   current meta-openembedded recipe for accel-ppp reads:
> >
> > PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27"
> >
> > with error logged here:
> >
> > http://errors.yoctoproject.org/Errors/Details/81003/
> >
> >   just tried under latest poky pull containing binutils-2.28
> >
> > and it seems to compile just fine. should it be unblacklisted?
> >
> > rday
> >
> How about sending a patch and give Martin's world a try?
>
> Andreas
> --
> ___
> 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] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Andreas Müller
On Mon, Mar 20, 2017 at 12:56 PM, Robert P. J. Day
 wrote:
>
>   current meta-openembedded recipe for accel-ppp reads:
>
> PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27"
>
> with error logged here:
>
> http://errors.yoctoproject.org/Errors/Details/81003/
>
>   just tried under latest poky pull containing binutils-2.28
>
> and it seems to compile just fine. should it be unblacklisted?
>
> rday
>
How about sending a patch and give Martin's world a try?

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


[oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28

2017-03-20 Thread Robert P. J. Day

  current meta-openembedded recipe for accel-ppp reads:

PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27"

with error logged here:

http://errors.yoctoproject.org/Errors/Details/81003/

  just tried under latest poky pull containing binutils-2.28

and it seems to compile just fine. should it be unblacklisted?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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