Re: [yocto] Error do_compile libepoxy
On Wed, Jan 17, 2018 at 1:58 PM, Andrea Galbusera wrote: > Hi! > > On Wed, Jan 17, 2018 at 1:46 PM, Mathias Rudnik > wrote: >> Hello, >> >> I am trying to build libepoxy but the do_compile tasks breaks. >> I found following error messages in the logs: >> >> arm-poky-linux-gnueabi-gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard >> -mtune=arm1176jzf-s -mfpu=vfp >> --sysroot=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot >> '-Itest/egl_common at sta' '-Itest' '-Iinclude/epoxy' >> '-I../libepoxy-1.4.3/test' '-Iinclude' '-I../libepoxy-1.4.3/include' '-Isrc' >> '-I../libepoxy-1.4.3/src' '-fdiagnostics-color=always' '-pipe' >> '-D_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-std=gnu99' '-O2' '-g' >> '-O2' '-g' '-feliminate-unused-debug-types' >> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0' >> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot-native=' >> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot=' >> '-lEGL' '-fPIC' '-Wpointer-arith' '-Wmissing-declarations' '-Wformat=2' >> '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wnested-externs' >> '-Wbad-function-cast' '-Wold-style-definition' >> '-Wdeclaration-after-statement' '-Wunused' '-Wuninitialized' '-Wshadow' >> '-Wmissing-noreturn' '-Wmissing-format-attribute' '-Wredundant-decls' >> '-Wlogical-op' '-Werror=implicit' '-Werror=nonnull' '-Werror=init-self' >> '-Werror=main' '-Werror=missing-braces' '-Werror=sequence-point' >> '-Werror=return-type' '-Werror=trigraphs' '-Werror=array-bounds' >> '-Werror=write-strings' '-Werror=address' '-Werror=int-to-pointer-cast' >> '-Werror=pointer-to-int-cast' '-fno-strict-aliasing' '-Wno-int-conversion' >> '-MMD' '-MQ' 'test/egl_common at sta/egl_common.c.o' '-MF' 'test/egl_common >> at sta/egl_common.c.o.d' -o 'test/egl_common at sta/egl_common.c.o' -c >> ../libepoxy-1.4.3/test/egl_common.c >> ../libepoxy-1.4.3/test/egl_common.c: In function 'get_egl_display_or_skip': >> ../libepoxy-1.4.3/test/egl_common.c:36:5: error: unknown type name >> 'Display'; did you mean 'EGLDisplay'? >> Display *dpy = XOpenDisplay(NULL); >> ^~~ >> EGLDisplay >> ../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration of >> function 'XOpenDisplay'; did you mean 'eglGetDisplay'? >> [-Werror=implicit-function-declaration] >> Display *dpy = XOpenDisplay(NULL); >> ^~~~ >> eglGetDisplay >> ../libepoxy-1.4.3/test/egl_common.c:36:20: warning: nested extern >> declaration of 'XOpenDisplay' [-Wnested-externs] >> cc1: some warnings being treated as errors >> >> Does anybody know what i am doing wrong? > > Just noticed this also here in CI builds. Unfortunately I'm building > with lot of new stuff from master branches wrt latest successful > build. In my case meta-raspberrypi is in the pile, but I haven't had > the time to investigate yet. At first glance at least commit > 043f0218491452de223a5f0b47945fc6ec1633eb (libepoxy related) should be > in my bisecting range. Will report back if something comes up. Looks like my first guess was not that bad. Reverting below commit, which switched to meson build system brought my build back to green. Also CC-ing the patch author who might suggest further investigations. commit 043f0218491452de223a5f0b47945fc6ec1633eb Author: Alexander Kanavin AuthorDate: Thu Jan 4 15:12:33 2018 +0200 Commit: Richard Purdie CommitDate: Fri Jan 5 12:02:37 2018 + libepoxy: convert to meson build Add a patch to work around absence of dlvsym() on musl (wasn't previously a problem as autotools weren't building tests by default) (From OE-Core rev: aaa523e87c73abc2cf8cf3ea55d9e2c6789d3b9a) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie My configuration is as follows: Build Configuration: BB_VERSION = "1.37.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "raspberrypi3" DISTRO = "poky" DISTRO_VERSION = "2.4+snapshot-20180117" TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "HEAD:d7cf7d6d032158690d6503ddc2c20bc5cd614264" meta-oe meta-python meta-networking = "HEAD:8cef6b38e62e6c79ec857510df454cefc868b0df" meta-rauc= "HEAD:40277f38840fa851e15390169120a4822b867e1d" meta-swupdate= "HEAD:033c840bc17844894330dd5a913114f82ed28484" meta-sunxi = "HEAD:2c85181c9274654e2337284a59658132f1fc45b7" meta-raspberrypi = "HEAD:c47caaca325b8cd81ee5bcd7cb30295faf0d440d" meta-bsl = "HEAD:
Re: [yocto] Error do_compile libepoxy
On 18 January 2018 at 08:58, Andrea Galbusera wrote: > Looks like my first guess was not that bad. Reverting below commit, > which switched to meson build system brought my build back to green. > Also CC-ing the patch author who might suggest further investigations. > So you've implicated the Meson conversion. Again I suggest approaching upstream may be a better way to work this. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On 01/18/2018 10:58 AM, Andrea Galbusera wrote: Looks like my first guess was not that bad. Reverting below commit, which switched to meson build system brought my build back to green. Also CC-ing the patch author who might suggest further investigations. libepoxy: convert to meson build There's probably a missing header include - carefully compare do_compile logs in both cases and see how they differ for the failing file. Also inspect the file for any conditional define macros and see if they're enabled or not in both cases. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] conf/layer.conf: remove bbclass from BBFILES
Add bbclass to BBFILES doesn't make any sense.
Signed-off-by: Robert Yang
---
meta-security-compliance/conf/layer.conf | 2 +-
meta-tpm/conf/layer.conf | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-security-compliance/conf/layer.conf
b/meta-security-compliance/conf/layer.conf
index b1b9727..68d5528 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -2,7 +2,7 @@
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend
${LAYERDIR}/classes/*.bbclass"
+BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "scanners-layer"
BBFILE_PATTERN_scanners-layer = "^${LAYERDIR}/"
diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 5085db5..36486d1 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -2,7 +2,7 @@
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend
${LAYERDIR}/classes/*.bbclass"
+BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "tpm-layer"
BBFILE_PATTERN_tpm-layer = "^${LAYERDIR}/"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
FWIW: here nativesdk-libepoxy fails in do_configure already since meson conversion FileNotFoundError: [Errno 2] No such file or directory: 'TOPDIR/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-libepoxy/1.4.3-r0/build/meson-private/sanitycheckc.exe' http://errors.yoctoproject.org/Errors/Details/164799/ libepoxy in master doesn't support nativesdk yet (it's part of my changes to support virtglrenderer and spice in qemu). Is there some magic combination of settings meson needs to work for nativesdk? On Thu, Jan 18, 2018 at 10:05 AM, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 01/18/2018 10:58 AM, Andrea Galbusera wrote: > >> >> Looks like my first guess was not that bad. Reverting below commit, >> which switched to meson build system brought my build back to green. >> Also CC-ing the patch author who might suggest further investigations. >> >> libepoxy: convert to meson build >> >> > There's probably a missing header include - carefully compare do_compile > logs in both cases and see how they differ for the failing file. Also > inspect the file for any conditional define macros and see if they're > enabled or not in both cases. > > > Alex > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On 01/18/2018 12:00 PM, Martin Jansa wrote: FWIW: here nativesdk-libepoxy fails in do_configure already since meson conversion FileNotFoundError: [Errno 2] No such file or directory: 'TOPDIR/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-libepoxy/1.4.3-r0/build/meson-private/sanitycheckc.exe' http://errors.yoctoproject.org/Errors/Details/164799/ libepoxy in master doesn't support nativesdk yet (it's part of my changes to support virtglrenderer and spice in qemu). Is there some magic combination of settings meson needs to work for nativesdk? I don't know. There's an ongoing discussion in oe-core around this problem. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
Hi
2018-01-18 10:05 GMT+01:00 Alexander Kanavin <
alexander.kana...@linux.intel.com>:
> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>
>>
>> Looks like my first guess was not that bad. Reverting below commit,
>> which switched to meson build system brought my build back to green.
>> Also CC-ing the patch author who might suggest further investigations.
>>
>> libepoxy: convert to meson build
>>
>>
> There's probably a missing header include - carefully compare do_compile
> logs in both cases and see how they differ for the failing file. Also
> inspect the file for any conditional define macros and see if they're
> enabled or not in both cases.
>
>
I've seen this also with a build for Nviidia Tegras which have non
'standard' (i.e. not from the mesa build) EGL/OpenGLES header files. (And
there is no OpenGL/GLX.)
Above error and a linking attempt against the not existing GLX are both in
the test binaries produced from the libepoxy-1.4.3/test directory. All
artefacts from in there are not packaged by our recipe. Before the switch
to meson those binaries were not built, so I guess that the issues have
been there all along but they did not trigger.
My interim fix is to remove the test directory from the top-level
meson.build file but I'm unsure if that is a way forward.
I did not yet build nativesdk-libepoxy with this.
--- libepoxy-1.4.3/meson.build~ 2017-06-06 11:55:31.0 +0200
+++ libepoxy-1.4.3/meson.build 2018-01-18 14:10:49.517098475 +0100
@@ -258,7 +258,6 @@
subdir('include/epoxy')
subdir('src')
-subdir('test')
if get_option('enable-docs')
doxygen = find_program('doxygen', required: false)
[
Max
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On Thu, Jan 18, 2018 at 2:13 PM, Max Krummenacher wrote:
> Hi
>
> 2018-01-18 10:05 GMT+01:00 Alexander Kanavin
> :
>>
>> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>>>
>>>
>>> Looks like my first guess was not that bad. Reverting below commit,
>>> which switched to meson build system brought my build back to green.
>>> Also CC-ing the patch author who might suggest further investigations.
>>>
>>> libepoxy: convert to meson build
>>>
>>
>> There's probably a missing header include - carefully compare do_compile
>> logs in both cases and see how they differ for the failing file. Also
>> inspect the file for any conditional define macros and see if they're
>> enabled or not in both cases.
>>
>
> I've seen this also with a build for Nviidia Tegras which have non
> 'standard' (i.e. not from the mesa build) EGL/OpenGLES header files. (And
> there is no OpenGL/GLX.)
>
> Above error and a linking attempt against the not existing GLX are both in
> the test binaries produced from the libepoxy-1.4.3/test directory. All
> artefacts from in there are not packaged by our recipe. Before the switch to
> meson those binaries were not built, so I guess that the issues have been
> there all along but they did not trigger.
>
> My interim fix is to remove the test directory from the top-level
> meson.build file but I'm unsure if that is a way forward.
> I did not yet build nativesdk-libepoxy with this.
>
> --- libepoxy-1.4.3/meson.build~ 2017-06-06 11:55:31.0 +0200
> +++ libepoxy-1.4.3/meson.build 2018-01-18 14:10:49.517098475 +0100
> @@ -258,7 +258,6 @@
>
> subdir('include/epoxy')
> subdir('src')
> -subdir('test')
>
> if get_option('enable-docs')
>doxygen = find_program('doxygen', required: false)
> [
>
> Max
Yes, this is coherent with what Alexander's commit message says. We
started building stuff in test/ while switching to meson...
If we can't easily fix the upstream ourself and/or reproduce outside
of OE to ask for help from upstream devels, IMO we should temporarily
prevent meson from building the tests.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On 01/18/2018 03:41 PM, Andrea Galbusera wrote: Yes, this is coherent with what Alexander's commit message says. We started building stuff in test/ while switching to meson... If we can't easily fix the upstream ourself and/or reproduce outside of OE to ask for help from upstream devels, IMO we should temporarily prevent meson from building the tests. Note that this same test does build fine in poky, so disabling the tests is not a good fix. You should figure out what is about the non-poky EGL headers that is causing the failure, and whether you need to configure the provider of those headers differently, or add missing dependencies etc. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Running cmake in the SDK environment from a script fails
2018-01-17 20:30 GMT+01:00 Bartosz Golaszewski : > Hi, > > I'm working on a project in which a base linux distribution is built > using yocto while a set of proprietary components is built with the > generated SDK (-c populate_sdk). > > These components use cmake for building. While they build just fine > when the 'cmake' command is invoked from command-line, as soon as > there's a fork() and execve() in between (e.g. when cmake is invoked > from a script or even when I tried tracing it with strace), the build > fails on finding any external library: > > -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.8") > CMake Error at cmake/external_dependencies.cmake:10 (message): > Could not find zlib > Call Stack (most recent call first): > CMakeLists.txt:109 (include) > > The 'found' message is there because it eventually 'found' my host's > header as visible in the strace output[1]. > > The target arch is core2-64 while the host is x86_64. Both host and > target dirs are present in sysroots/. > > What's clear when browsing the strace output is that the headers are > not searched for in the right directory which would in this case be > sysroots/core2-64-poky-linux/usr/include/ but in > /sysroots/x86_64-pokysdk-linux/ instead. > > I initially thought this to be a problem with the project's > CMakeLists.txt but it seems fine given the fact that it builds when > used manually. > > Any idea what could be the culprit here? > > Best regards, > Bartosz Golaszewski > > [1] https://pastebin.com/1pqmbh7R After some more debugging I found the culprit. The environment setup script in the SDK aliases cmake to 'cmake -DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake' but aliases are not expanded in non-interactive shells by default. It can be fixed with shopt or by passing this parameter explicitly to cmake. I didn't find any mention of that anywhere in docs. Any idea for a right place to put it in? Thanks, Bartosz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On Thu, Jan 18, 2018 at 4:05 AM, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 01/18/2018 10:58 AM, Andrea Galbusera wrote: > >> >> Looks like my first guess was not that bad. Reverting below commit, >> which switched to meson build system brought my build back to green. >> Also CC-ing the patch author who might suggest further investigations. >> >> libepoxy: convert to meson build >> >> > There's probably a missing header include > > The original error: ../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration of function 'XOpenDisplay'; did you mean 'eglGetDisplay'? [-Werror=implicit-function-declaration] Display *dpy = XOpenDisplay(NULL); implies a missing #include -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Add Python 3 custom package to native tools
Hi all, I want to add the Python 3 custom package foo to my native host tools to execute its executable in a class. How could I do that? I already inherited distutils3 to my foo recipe, but when I launch foo with oe-run-native, the error pkg_resources.DistributionNotFound: The 'foo=1.0' distribution was not found and is required by the application pops up. But foo with its accompanying 1.0 .egg is already in tmp/sysroots-components/x86_64/foo-native/usr/lib/python3.5/site-packages. Is another class or environment variable needed? Regards, Jan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] do_roots braking after a SRCREV update for non master branch
Hi,
I've updated my recipe to use a review from a non master branch:
Old version [python3-senichub_git.bb]:
inherit setuptools3
PROVIDES += "python3-senic-hub"
RPROVIDES_${PN} += "python3-senic-hub"
S = "${WORKDIR}/git"
SRC_URI = "git://github.com/getsenic/senic-hub.git;"
SRCREV = "01fd5bd8725add5e73d3cc35a169f0dc837daefa"
PV = "git-${SRCPV}"
RDEPENDS_${PN} = "python3-nuimo python3-lightify"
New version [python3-senichub_git.bb]:
inherit setuptools3
PROVIDES += "python3-senic-hub"
RPROVIDES_${PN} += "python3-senic-hub"
S = "${WORKDIR}/git"
SRC_URI = "git://github.com/getsenic/senic-hub.git;branch=improve-logging;"
SRCREV = "ad6c082a8a990291c6128f54ea0c0d185081704e"
PV = "git-${SRCPV}"
RDEPENDS_${PN} = "python3-nuimo python3-lightify"
So the only changes is the SRCREV, and a specific
branch in the SRC_URI.
The package alone builds successfully.
But when building the image it fails on the do_rootfs:
opkg_prepare_url_for_install: Couldn't find anything to satisfy
'python3-senic-hub'.
I can't really make the causes of it. There are some legacy
naming inconsistencies with a dash, but there is an explicit
PROVIDES and RPROVIDES in both recipes, one fails the
other passes.
Any ideas?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_roots braking after a SRCREV update for non master branch
I'd check (using oe-pkgdata-util and/or buildhistory-diff) that the new
package is building the same files and packages as the old one. If PN
wasn't being generated, that would explain why the provides isn't working.
Ross
On 18 January 2018 at 14:46, Alan Martinovic
wrote:
> Hi,
> I've updated my recipe to use a review from a non master branch:
>
> Old version [python3-senichub_git.bb]:
>
> inherit setuptools3
>
> PROVIDES += "python3-senic-hub"
> RPROVIDES_${PN} += "python3-senic-hub"
>
> S = "${WORKDIR}/git"
> SRC_URI = "git://github.com/getsenic/senic-hub.git;"
> SRCREV = "01fd5bd8725add5e73d3cc35a169f0dc837daefa"
> PV = "git-${SRCPV}"
>
> RDEPENDS_${PN} = "python3-nuimo python3-lightify"
>
> New version [python3-senichub_git.bb]:
>
> inherit setuptools3
>
> PROVIDES += "python3-senic-hub"
> RPROVIDES_${PN} += "python3-senic-hub"
>
> S = "${WORKDIR}/git"
> SRC_URI = "git://github.com/getsenic/senic-hub.git;branch=improve-
> logging;"
> SRCREV = "ad6c082a8a990291c6128f54ea0c0d185081704e"
> PV = "git-${SRCPV}"
>
> RDEPENDS_${PN} = "python3-nuimo python3-lightify"
>
>
> So the only changes is the SRCREV, and a specific
> branch in the SRC_URI.
> The package alone builds successfully.
> But when building the image it fails on the do_rootfs:
>
> opkg_prepare_url_for_install: Couldn't find anything to satisfy
> 'python3-senic-hub'.
>
> I can't really make the causes of it. There are some legacy
> naming inconsistencies with a dash, but there is an explicit
> PROVIDES and RPROVIDES in both recipes, one fails the
> other passes.
>
> Any ideas?
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
I can confirm adding #include to test/egl_common.c gets past the original error, but then fails with: Log data follows: | DEBUG: Executing shell function do_compile | [1/2] Compiling c object 'test/glx_beginend@exe/glx_beginend.c.o' | [2/2] Linking target test/glx_beginend | FAILED: test/glx_beginend | arm-poky-linux-gnueabi-gcc -o test/glx_beginend 'test/glx_beginend@exe/glx_beginend.c.o' '-Wl,--no-undefined' '-Wl,--as-needed' '-O2' '-pipe' '-g' '-feliminate-unused-debug-types' '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0' '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot-native=' '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot=' '-Wl,-O1' '-Wl,--hash-style=gnu' '-Wl,--as-needed' 'test/libglx_common.a' 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' '-ldl' '-lX11' '-ldl' '-Wl,-rpath,/home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/build/src' -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed | test/glx_beginend@exe/glx_beginend.c.o: In function `test_without_epoxy': | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:70: undefined reference to `glBegin' | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:85: undefined reference to `glEnd' | collect2: error: ld returned 1 exit status | ninja: build stopped: subcommand failed. | WARNING: /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/run.do_compile.2610:1 exit 1 from 'ninja -j 8' | ERROR: Function failed: do_compile (log file is located at /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/log.do_compile.2610) ERROR: Task (/home/michael/oe/recipes/poky/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb:do_compile) failed with exit code '1' Michael Gloff On Thu, Jan 18, 2018 at 8:08 AM, Trevor Woerner wrote: > On Thu, Jan 18, 2018 at 4:05 AM, Alexander Kanavin < > alexander.kana...@linux.intel.com> wrote: > >> On 01/18/2018 10:58 AM, Andrea Galbusera wrote: >> >>> >>> Looks like my first guess was not that bad. Reverting below commit, >>> which switched to meson build system brought my build back to green. >>> Also CC-ing the patch author who might suggest further investigations. >>> >>> libepoxy: convert to meson build >>> >>> >> There's probably a missing header include >> >> > > The original error: > > > ../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration of > function 'XOpenDisplay'; did you mean 'eglGetDisplay'? > [-Werror=implicit-function-declaration] > Display *dpy = XOpenDisplay(NULL); > > implies a missing #include > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.2.3.rc2 now available.
A release candidate build for yocto-2.2.3.rc2 is now available at: https://autobuilder.yocto.io/pub/releases/yocto-2.2.3.rc2 Please begin QA on this build as soon as possible. Build hash information: meta-intel : c781510a5a6b45e60cc32b6614ddcce3f1452121 meta-qt4 : f389368dc86e745df14cab9eeb9a94bc02bd273e meta-mingw : 58dda8440c1943c15ee750eb40f0fc651e316f51 meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f meta-gplv2 : c7f97f199a6dd54d3f369f0465a6bfd2cfa739b9 poky : e6626951501cdf8c5516ad42fd585894f19c2327 \nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: git://git.yoctoproject.org/yocto-autobuilder\nEmail: joshua.g.l...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] Fwd: How to make the os-release package work with local walltime instead of GMT?
On Mon, Jan 15, 2018 at 9:20 PM, Trevor Woerner wrote:
> On Thu, Jan 11, 2018 at 12:26 AM, Robert Yang
> wrote:
>>
>> BUILD_ID = "${@time.strftime('%Y-%m-%d %H:%M:%S',time.localtime())}"
>
> Brilliant! Why isn't this the default?
Using localtime could cause confusion for teams which span different time zones.
Even if everyone is in the same time zone, it can also give unexpected
results when entering or leaving daylight savings time.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On Thu, Jan 18, 2018 at 10:05 AM, Michael Gloff wrote: > I can confirm adding #include to test/egl_common.c gets past > the original error, but then fails with: > > thank you for checking :-) > > > Log data follows: > | DEBUG: Executing shell function do_compile > | [1/2] Compiling c object 'test/glx_beginend@exe/glx_beginend.c.o' > | [2/2] Linking target test/glx_beginend > | FAILED: test/glx_beginend > | arm-poky-linux-gnueabi-gcc -o test/glx_beginend 'test/glx_beginend@exe > /glx_beginend.c.o' '-Wl,--no-undefined' '-Wl,--as-needed' '-O2' '-pipe' > '-g' '-feliminate-unused-debug-types' '-fdebug-prefix-map=/home/ > michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon- > vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0' > '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/ > tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ > libepoxy/1.4.3-r0/recipe-sysroot-native=' '-fdebug-prefix-map=/home/ > michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon- > vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot=' '-Wl,-O1' > '-Wl,--hash-style=gnu' '-Wl,--as-needed' 'test/libglx_common.a' > 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' > '-ldl' '-lX11' '-ldl' '-Wl,-rpath,/home/michael/oe/ > recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky- > linux-gnueabi/libepoxy/1.4.3-r0/build/src' -march=armv7ve -marm > -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 > --sysroot=/home/michael/oe/recipes/rpi-build/tmp/work/ > cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot > -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed > | test/glx_beginend@exe/glx_beginend.c.o: In function > `test_without_epoxy': > | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:70: > undefined reference to `glBegin' > | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:85: > undefined reference to `glEnd' > | collect2: error: ld returned 1 exit status > | ninja: build stopped: subcommand failed. > | WARNING: /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf- > neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/run.do_compile.2610:1 > exit 1 from 'ninja -j 8' > | ERROR: Function failed: do_compile (log file is located at > /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf- > neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/log.do_compile.2610) > ERROR: Task (/home/michael/oe/recipes/poky/meta/recipes-graphics/ > libepoxy/libepoxy_1.4.3.bb:do_compile) failed with exit code '1' > > that suggests a missing #include -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oic][PATCH resend 1/5] iotivity_1.2.1: Hotfix: Add ORIGIN rpath for binutils-2.29
Set RPATH to ORIGIN as supported by gcc/ld (-rpath=\$ORIGIN)
Observed issue on poky master was:
ld: warning: libconnectivity_abstraction.so, \
needed by out/yocto/x86_64/release/liboctbstack.so,
not found (try using -rpath or -rpath-link)
out/yocto/x86_64/release/liboctbstack.so: \
undefined reference to `coap_write_block_opt'
Note that problem is also about
to be fixed upstream directly in scons files.
Bug: https://jira.iotivity.org/browse/IOT-2651
Relate-to: https://gerrit.iotivity.org/gerrit/#/c/22355/
Thanks-to: Mikko Ylinen
Signed-off-by: Philippe Coval
---
recipes-core/iotivity/iotivity_1.2.1.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-core/iotivity/iotivity_1.2.1.bb
b/recipes-core/iotivity/iotivity_1.2.1.bb
index c8fb8fd..33adb9a 100644
--- a/recipes-core/iotivity/iotivity_1.2.1.bb
+++ b/recipes-core/iotivity/iotivity_1.2.1.bb
@@ -53,6 +53,7 @@ python () {
IOTIVITY_BIN_DIR = "/opt/${PN}"
IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+LDFLAGS_append = " -Wl,-rpath-link=\\$$ORIGIN"
do_compile_prepend() {
export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oic][PATCH resend 2/5] Add recipe for IoTivity 1.3.0
Note that SECURITY is now enabled but might cause issues on some examples.
Bug: https://jira.iotivity.org/browse/IOT-2651
Signed-off-by: Philippe Coval
---
README | 2 +-
...ging-Return-false-boolean-instead-of-enum.patch | 40 ++
recipes-core/iotivity/iotivity_1.3.0.bb| 471 +
3 files changed, 512 insertions(+), 1 deletion(-)
create mode 100644
recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
create mode 100644 recipes-core/iotivity/iotivity_1.3.0.bb
diff --git a/README b/README
index ef202dd..085dbdc 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
meta-oic
-This layer contains recipes for the IoTivity Project (v1.2.1)
+This layer contains recipes for the IoTivity Project (v1.3.0)
, sample applications and related components for any Yocto target.
Contents
diff --git
a/recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
b/recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
new file mode 100644
index 000..101588d
--- /dev/null
+++
b/recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
@@ -0,0 +1,40 @@
+From 45a915954650b0c2f5752ae9e958a194d2483852 Mon Sep 17 00:00:00 2001
+From: Philippe Coval
+Date: Wed, 28 Jun 2017 04:54:05 +0200
+Subject: [PATCH 099/169] bridging: Return false boolean instead of enum
+
+Small Fix to support g++-7.1.0
+
+It was tested on yocto poky master on iotivity-1.3.0 (and later):
+
+ bridging/plugins/nest_plugin/nest_objects/nest.cpp: \
+ In member function 'bool Nest::isAuthorized()':
+ bridging/plugins/nest_plugin/nest_objects/nest.cpp:95:16: \
+ error: enum constant in boolean context [-Werror=int-in-bool-context]
+
+
+Signed-off-by: Philippe Coval
+Reviewed-on: https://gerrit.iotivity.org/gerrit/21071
+Tested-by: jenkins-iotivity
+Reviewed-by: Dan Mihai
+Reviewed-by: Todd Malsbary
+---
+ bridging/plugins/nest_plugin/nest_objects/nest.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bridging/plugins/nest_plugin/nest_objects/nest.cpp
b/bridging/plugins/nest_plugin/nest_objects/nest.cpp
+index 780d6e9..8b40848 100644
+--- a/bridging/plugins/nest_plugin/nest_objects/nest.cpp
b/bridging/plugins/nest_plugin/nest_objects/nest.cpp
+@@ -92,7 +92,7 @@ bool Nest::isAuthorized()
+ if (curlCode != MPM_RESULT_OK)
+ {
+ OIC_LOG_V(ERROR, TAG, "Curl GET Request operation failed. Error code
%d", curlCode);
+-return MPM_RESULT_INTERNAL_ERROR;
++return false;
+ }
+
+ if (MPM_RESULT_OK != parseStructureJsonResponse(response, m_metaInfo))
+--
+1.9.1
+
diff --git a/recipes-core/iotivity/iotivity_1.3.0.bb
b/recipes-core/iotivity/iotivity_1.3.0.bb
new file mode 100644
index 000..b1490dd
--- /dev/null
+++ b/recipes-core/iotivity/iotivity_1.3.0.bb
@@ -0,0 +1,471 @@
+SUMMARY = "IoTivity framework and SDK sponsored by the Open Connectivity
Foundation."
+DESCRIPTION = "IoTivity is an open source software framework enabling seamless
device-to-device connectivity to address the emerging needs of the Internet of
Things."
+HOMEPAGE = "https://www.iotivity.org/";
+DEPENDS = "boost virtual/gettext chrpath-replacement-native expat openssl
util-linux curl glib-2.0 glib-2.0-native"
+DEPENDS += "sqlite3"
+
+EXTRANATIVEPATH += "chrpath-native"
+SECTION = "libs"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=22bf216f3077c279aed7b36b1fa9e6d1"
+
+branch_iotivity ?= "1.3-rel"
+SRCREV ?= "443b33a031f275380d1a50ac8c2ac20b80292fb1"
+url_iotivity ?=
"git://github.com/iotivity/iotivity.git;destsuffix=${S};branch=${branch_iotivity};protocol=http"
+SRC_URI += "${url_iotivity}"
+SRC_URI += "file://0189-resource-Include-functional-header-for-g-7.1.0.patch"
+SRC_URI += "file://0099-bridging-Return-false-boolean-instead-of-enum.patch"
+
+url_tinycbor = "git://github.com/01org/tinycbor.git"
+SRCREV_tinycbor = "31c7f81d45d115d2007b1c881cbbd3a19618465c"
+SRC_URI +=
"${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http"
+
+url_gtest = "https://github.com/google/googletest/archive/release-1.7.0.zip";
+SRC_URI[gtest.md5sum] = "ef5e700c8a0f3ee123e2e0209b8b4961"
+SRC_URI[gtest.sha256sum] =
"b58cb7547a28b2c718d1e38aee18a3659c9e3ff52440297e965f5edffe34b6d0"
+SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest"
+
+url_hippomocks = "git://github.com/dascandy/hippomocks.git"
+SRCREV_hippomocks = "dca4725496abb0e41f8b582dec21d124f830a8e5"
+SRC_URI +=
"${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks/hippomocks;protocol=http"
+SRC_URI += "file://hippomocks_mips_patch"
+
+SRCREV_mbedtls = "85c2a928ed352845793db000e78e2b42c8dcf055"
+url_mbedtls="git://github.com/ARMmbed/mbedtls.git"
+SRC_URI +=
"${url_mbedtls};name=mbedtls;destsuffix=${S}/extlibs/mbedtls/mbedtls;protocol=http"
+
+url_rapidjson = "git://github.com/miloyip/rapidjson.g
[yocto] [meta-oic][PATCH resend 3/5] iotivity-simple-client: Support pkg-config
Since IoTivity-1.3.0
Signed-off-by: Philippe Coval
---
.../files/0002-build-Use-pkg-config.patch | 43 ++
.../iotivity-simple-client_1.1.0.bb| 8 +++-
2 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644
recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch
diff --git
a/recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch
b/recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch
new file mode 100644
index 000..026f68f
--- /dev/null
+++ b/recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch
@@ -0,0 +1,43 @@
+From 0a1f2273605ce775aede46ab3ec31bd73814f8b2 Mon Sep 17 00:00:00 2001
+From: Philippe Coval
+Date: Tue, 6 Jun 2017 17:14:39 +0200
+Subject: [PATCH 2/2] build: Use pkg-config
+
+
+Bug: https://jira.iotivity.org/browse/IOT-
+Origin: https://github.com/TizenTeam/meta-oic
+Signed-off-by: Philippe Coval
+---
+ Makefile | 17 -
+ 1 file changed, 4 insertions(+), 13 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 2389f43..ac34940 100644
+--- a/Makefile
b/Makefile
+@@ -1,18 +1,9 @@
+-YOCTOCXXFLAGS=-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/stack
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/ocrandom
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/logger
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/oc_logger
+-
+-YOCTOLDFLAGS=-loc -loctbstack -loc_logger
++PKG_CONFIG?=pkg-config
++override CPPFLAGS+=$(shell ${PKG_CONFIG} iotivity --cflags)
++override LDLIBS+=$(shell ${PKG_CONFIG} iotivity --libs)
++override CXXFLAGS+=-std=c++0x
+
+ all: simpleclient
+
+-simpleclient.o: simpleclient.cpp
+-ifeq ($(PKG_CONFIG_SYSROOT_DIR),)
+- echo "Error: Yocto cross-toolchain environment not initialized"
+- exit 1
+-endif
+- $(CXX) -std=c++0x -c -o $@ $< $(YOCTOCXXFLAGS)
+-
+-simpleclient: simpleclient.o
+- $(CXX) -o $@ $^ $(LDFLAGS) $(YOCTOLDFLAGS)
+-
+ clean:
+ rm -rf simpleclient *.o
+--
+1.9.1
+
diff --git
a/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
b/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
index caf02f8..ea3bd64 100644
--- a/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
+++ b/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
@@ -1,3 +1,6 @@
+#TODO
+PR = "r1"
+
SUMMARY = "Iotivity Simple Client"
DESCRIPTION = "Iotivity Simple Client example which talks to the Simple Server
example."
HOMEPAGE = "https://www.iotivity.org/";
@@ -8,17 +11,20 @@ LIC_FILES_CHKSUM =
"file://simpleclient.cpp;beginline=1;endline=19;md5=fc5a615cf
SRC_URI = "file://iotivity-simple-client.tar.bz2 \
file://0001-build-Use-LDFLAGS-variable-from-env.patch \
+file://0002-build-Use-pkg-config.patch \
"
S = "${WORKDIR}/iotivity-simple-client"
IOTIVITY_BIN_DIR = "/opt/iotivity"
IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+inherit pkgconfig
do_install() {
install -d ${IOTIVITY_BIN_DIR_D}/apps/iotivity-simple-client
install -c -m 555 ${S}/simpleclient
${IOTIVITY_BIN_DIR_D}/apps/iotivity-simple-client
install -c -m 444 ${S}/oic_svr_db_client.dat
${IOTIVITY_BIN_DIR_D}/apps/iotivity-simple-client
+rm -rf ${D}/usr/src/debug/${PN}
}
FILES_${PN} = "${IOTIVITY_BIN_DIR}/apps/iotivity-simple-client/simpleclient \
@@ -26,4 +32,4 @@ FILES_${PN} =
"${IOTIVITY_BIN_DIR}/apps/iotivity-simple-client/simpleclient \
FILES_${PN}-dbg = "${IOTIVITY_BIN_DIR}/apps/iotivity-simple-client/.debug"
RDEPENDS_${PN} += "iotivity-resource"
BBCLASSEXTEND = "native nativesdk"
-
+PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oic][PATCH resend 4/5] iotivity-sensorboard: Support pkg-config
Since IoTivity-1.3.0
Signed-off-by: Philippe Coval
---
.../files/0003-server-Port-to-iotivity-1.2.0.patch | 68 ++
.../files/0004-build-Use-pkg-config.patch | 48 +++
.../iotivity-sensorboard_1.0.0.bb | 11
3 files changed, 127 insertions(+)
create mode 100644
recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
create mode 100644
recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch
diff --git
a/recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
b/recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
new file mode 100644
index 000..6f59e6a
--- /dev/null
+++
b/recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
@@ -0,0 +1,68 @@
+From dcc5e1fd4204f08126ff940232283347b4963b15 Mon Sep 17 00:00:00 2001
+From: Philippe Coval
+Date: Thu, 20 Jul 2017 15:33:36 +0200
+Subject: [PATCH 3/4] server: Port to iotivity-1.2.0+
+
+Bug: https://jira.iotivity.org/browse/IOT-
+
+Origin: https://github.com/TizenTeam/meta-oic/tree/iotivity-sensorboard/master
+Signed-off-by: Philippe Coval
+---
+ server.cpp | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/server.cpp b/server.cpp
+index 8308577..5cb3215 100644
+--- a/server.cpp
b/server.cpp
+@@ -107,7 +107,6 @@ void IoTServer::temperatureObserverLoop()
+ usleep(150);
+ cout << "Temperature Observer Callback" << endl;
+ shared_ptr resourceResponse(new OCResourceResponse());
+-resourceResponse->setErrorCode(200);
+
resourceResponse->setResourceRepresentation(getTemperatureRepresentation(),
+ EDISON_RESOURCE_INTERFACE);
+ OCStackResult result =
OCPlatform::notifyListOfObservers(m_temperatureResource,
+@@ -125,7 +124,6 @@ void IoTServer::lightObserverLoop()
+ usleep(150);
+ cout << "Light Observer Callback" << endl;
+ shared_ptr resourceResponse(new OCResourceResponse());
+-resourceResponse->setErrorCode(200);
+ resourceResponse->setResourceRepresentation(getLightRepresentation(),
+ EDISON_RESOURCE_INTERFACE);
+ OCStackResult result =
OCPlatform::notifyListOfObservers(m_ambientLightResource,
+@@ -167,7 +165,6 @@ OCEntityHandlerResult
IoTServer::lightEntityHandler(shared_ptrsetErrorCode(200);
+ Response->setResponseResult(OC_EH_OK);
+
Response->setResourceRepresentation(getLightRepresentation());
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+@@ -224,7 +221,6 @@ OCEntityHandlerResult
IoTServer::temperatureEntityHandler(shared_ptrsetErrorCode(200);
+ Response->setResponseResult(OC_EH_OK);
+
Response->setResourceRepresentation(getTemperatureRepresentation());
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+@@ -305,7 +301,6 @@ OCEntityHandlerResult
IoTServer::LEDEntityHandler(shared_ptr
+ putLEDRepresentation();
+ if (Response)
+ {
+-Response->setErrorCode(200);
+
Response->setResourceRepresentation(getLEDRepresentation());
+ Response->setResponseResult(OC_EH_OK);
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+@@ -319,7 +314,6 @@ OCEntityHandlerResult
IoTServer::LEDEntityHandler(shared_ptr
+ cout << "GET request for platform LED" << endl;
+ if (Response)
+ {
+-Response->setErrorCode(200);
+
Response->setResourceRepresentation(getLEDRepresentation());
+ Response->setResponseResult(OC_EH_OK);
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+--
+1.9.1
+
diff --git
a/recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch
b/recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch
new file mode 100644
index 000..12f9323
--- /dev/null
+++ b/recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch
@@ -0,0 +1,48 @@
+From eace0b8280eda68aacbc396b9fe6756298af81b1 Mon Sep 17 00:00:00 2001
+From: Philippe Coval
+Date: Thu, 20 Jul 2017 15:22:56 +0200
+Subject: [PATCH 4/4] build: Use pkg-config
+
+Bug: https://jira.iotivity.org/browse/IOT-
+Origin: https://github.com/TizenTeam/meta-oic/tree/iotivity-sensorboard/master
+
+Signed-off-by: Philippe Coval
+---
+ Makefile | 17 -
+ 1 file changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 5d09cc1..ab3d632 100644
+--- a/Makefile
b/Makefile
+@@ -1,19 +1,18 @@
+-YOCTOCXXFLAGS=-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/stack
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/ocrandom
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/logger
-I$(PKG_C
[yocto] [meta-oic][PATCH resend 5/5] Add recipe for IoTivity 1.3.1
Note that fail on warning flag has been added,
and can be used in .bbappend if needed after reporting bugs:
http://wiki.iotivity.org/report
Bug: https://jira.iotivity.org/browse/IOT-2651
Signed-off-by: Philippe Coval
---
Origin:
https://github.com/tizenteam/meta-oic/tree/sandbox/pcoval/on/master/review
README | 2 +-
recipes-core/iotivity/iotivity_1.3.1.bb | 469
2 files changed, 470 insertions(+), 1 deletion(-)
create mode 100644 recipes-core/iotivity/iotivity_1.3.1.bb
diff --git a/README b/README
index 085dbdc..ca0c762 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
meta-oic
-This layer contains recipes for the IoTivity Project (v1.3.0)
+This layer contains recipes for the IoTivity Project (v1.3.1)
, sample applications and related components for any Yocto target.
Contents
diff --git a/recipes-core/iotivity/iotivity_1.3.1.bb
b/recipes-core/iotivity/iotivity_1.3.1.bb
new file mode 100644
index 000..c7b9163
--- /dev/null
+++ b/recipes-core/iotivity/iotivity_1.3.1.bb
@@ -0,0 +1,469 @@
+SUMMARY = "IoTivity framework and SDK sponsored by the Open Connectivity
Foundation."
+DESCRIPTION = "IoTivity is an open source software framework enabling seamless
device-to-device connectivity to address the emerging needs of the Internet of
Things."
+HOMEPAGE = "https://www.iotivity.org/";
+DEPENDS = "boost virtual/gettext chrpath-replacement-native expat openssl
util-linux curl glib-2.0 glib-2.0-native"
+DEPENDS += "sqlite3"
+
+EXTRANATIVEPATH += "chrpath-native"
+SECTION = "libs"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=22bf216f3077c279aed7b36b1fa9e6d1"
+
+branch_iotivity ?= "1.3-rel"
+SRCREV ?= "633dc231b8d9967520627528a92506efca7cebcd"
+url_iotivity ?=
"git://github.com/iotivity/iotivity.git;destsuffix=${S};branch=${branch_iotivity};protocol=http"
+SRC_URI += "${url_iotivity}"
+
+url_tinycbor = "git://github.com/01org/tinycbor.git"
+SRCREV_tinycbor = "31c7f81d45d115d2007b1c881cbbd3a19618465c"
+SRC_URI +=
"${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http"
+
+url_gtest = "https://github.com/google/googletest/archive/release-1.7.0.zip";
+SRC_URI[gtest.md5sum] = "ef5e700c8a0f3ee123e2e0209b8b4961"
+SRC_URI[gtest.sha256sum] =
"b58cb7547a28b2c718d1e38aee18a3659c9e3ff52440297e965f5edffe34b6d0"
+SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest"
+
+url_hippomocks = "git://github.com/dascandy/hippomocks.git"
+SRCREV_hippomocks = "dca4725496abb0e41f8b582dec21d124f830a8e5"
+SRC_URI +=
"${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks/hippomocks;protocol=http"
+SRC_URI += "file://hippomocks_mips_patch"
+
+SRCREV_mbedtls = "85c2a928ed352845793db000e78e2b42c8dcf055"
+url_mbedtls="git://github.com/ARMmbed/mbedtls.git"
+SRC_URI +=
"${url_mbedtls};name=mbedtls;destsuffix=${S}/extlibs/mbedtls/mbedtls;protocol=http"
+
+url_rapidjson = "git://github.com/miloyip/rapidjson.git"
+SRCREV_rapidjson = "3d5848a7cd3367c5cb451c6493165b7745948308"
+SRC_URI +=
"${url_rapidjson};name=rapidjson;;nobranch=1;destsuffix=${S}/extlibs/rapidjson/rapidjson;protocol=http"
+
+
+inherit pkgconfig scons
+
+
+python () {
+IOTIVITY_TARGET_ARCH = d.getVar("TARGET_ARCH", True)
+d.setVar("IOTIVITY_TARGET_ARCH", IOTIVITY_TARGET_ARCH)
+EXTRA_OESCONS = d.getVar("EXTRA_OESCONS", True)
+EXTRA_OESCONS += " TARGET_OS=yocto TARGET_ARCH=" + IOTIVITY_TARGET_ARCH +
" RELEASE=1"
+EXTRA_OESCONS += " VERBOSE=1"
+# Aligned to default configuration, but features can be changed here (at
your own risk):
+# EXTRA_OESCONS += " ERROR_ON_WARN=False"
+# EXTRA_OESCONS += " ROUTING=GW"
+# EXTRA_OESCONS += " SECURED=0"
+# EXTRA_OESCONS += " TCP=1"
+d.setVar("EXTRA_OESCONS", EXTRA_OESCONS)
+}
+
+
+IOTIVITY_BIN_DIR = "/opt/${PN}"
+IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+
+
+do_compile_prepend() {
+export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
+export PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\"
pkg-config"
+export LD_FLAGS="${LD_FLAGS}"
+}
+
+make_dir() {
+install -d $1
+}
+
+copy_file() {
+install -c -m 444 $1 $2
+}
+
+copy_exec() {
+install -c -m 555 $1 $2
+}
+
+copy_file_recursive() {
+cd $1 && find . -type d -exec install -d $2/"{}" \;
+cd $1 && find . -type f -exec install -c -m 444 "{}" $2/"{}" \;
+}
+
+copy_exec_recursive() {
+cd $1 && find . -executable -exec install -c -m 555 "{}" $2/"{}" \;
+}
+
+do_install_append() {
+make_dir ${D}${libdir}
+#Resource
+#C++ APIs
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboc.so
${D}${libdir}
+if ${@bb.utils.contains('EXTRA_OESCONS', 'SECURED=0', 'false', 'true',
d)}; then
+copy_file
${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/libocprovision.so ${D}${libdir}
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/libocpmapi.so
${D}${libdir}
+fi
+
+#Logger
+copy_file ${S}/out
[yocto] [eclipse-poky][oxygen][PATCH] Update setup.sh to Oxygen.2 (4.7.2) release
From: Chin Huat Ang
Signed-off-by: Chin Huat Ang
Signed-off-by: Tim Orling
---
scripts/setup.sh | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/scripts/setup.sh b/scripts/setup.sh
index 340364f..4b160ea 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -92,12 +92,12 @@ fi
# prepare the base Eclipse installation in folder "eclipse"
ep_rel="R-"
-ep_ver="4.7"
-ep_date="-201706120950"
+ep_ver="4.7.2"
+ep_date="-201711300510"
P2_disabled=false
P2_no_dropins=false
-if [ ! -f eclipse/plugins/org.eclipse.swt_3.106.0.v20170608-0516.jar ]; then
+if [ ! -f eclipse/plugins/org.eclipse.swt_3.106.2.v20171129-0543.jar ]; then
pushd .
@@ -261,13 +261,18 @@
UPDATE_SITE="http://download.eclipse.org/eclipse/updates/4.7";
#CDT related
echo -e "\nPlease wait. Installing CDT.SDK.FEATURE.GROUP"
-CDTFEAT="9.3.0"
+CDTFEAT="9.4.0"
update_feature_remote ${MAIN_SITE} org.eclipse.cdt.sdk.feature.group ${CDTFEAT}
echo -e "\nPlease wait. Installing CDT.LAUNCH.REMOTE.FEATURE.GROUP"
-CDTREMOTEVER="9.3.0"
+CDTREMOTEVER="9.4.0"
update_feature_remote ${MAIN_SITE} org.eclipse.cdt.launch.remote.feature.group
${CDTREMOTEVER}
+#AUTOTOOLS
+echo -e "\nPlease wait. Installing AUTOTOOLS.FEATURE.GROUP"
+ATVER="9.4.0"
+update_feature_remote ${MAIN_SITE} org.eclipse.cdt.autotools.feature.group
${ATVER}
+
#TM Terminal (was RSE) related
echo -e "\nPlease wait. Installing TM.TERMINAL.FEATURE.FEATURE.GROUP"
TMTERMVER="4.3.0"
@@ -287,24 +292,19 @@ RSESDKVER="3.7.0"
update_feature_remote ${TM_SITE} org.eclipse.rse.sdk.feature.group ${RSESDKVER}
#echo -e "\nSkipping RSE.SDK.FEATURE.GROUP"
-RSE_TERMINALS
+#RSE_TERMINALS
echo -e "\nPlease wait. Installing RSE.TERMINALS.FEATURE.GROUP"
RSETERMVER="3.8.0"
update_feature_remote ${TM_SITE} org.eclipse.rse.terminals.feature.group
${RSETERMVER}
#echo -e "\nSkipping RSE.TERMINALS.FEATURE.GROUP"
-#AUTOTOOLS
-echo -e "\nPlease wait. Installing AUTOTOOLS.FEATURE.GROUP"
-ATVER="9.3.0"
-update_feature_remote ${MAIN_SITE} org.eclipse.cdt.autotools.feature.group
${ATVER}
-
#Lttng2
-TMF_CTF_REL="3.0.0"
+TMF_CTF_REL="3.2.0"
echo -e "\nPlease wait. Installing TRACECOMPASS.LTTNG2.UST.FEATURE.GROUP"
update_feature_remote ${MAIN_SITE}
org.eclipse.tracecompass.lttng2.ust.feature.group ${TMF_CTF_REL}
echo -e "\nPlease wait. Installing
OSGI.COMPATIBILITY.PLUGINS.FEATURE.FEATURE.GROUP"
-COMPAT_VER="1.1.0"
+COMPAT_VER="1.1.1"
update_feature_remote ${UPDATE_SITE}
org.eclipse.osgi.compatibility.plugins.feature.feature.group ${COMPAT_VER}
echo -e "\nYour build environment is successfully created."
--
2.13.6
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
Thanks Trevor - going in the right direction. There are no "GL" includes or libs in the recipe sysroot becuase userland does not provide it. Adding mesa-gl to DEPENDS allows it to complete. Not sure if this is the correct solution though. Michael Gloff On Thu, Jan 18, 2018 at 2:48 PM, Trevor Woerner wrote: > On Thu, Jan 18, 2018 at 10:05 AM, Michael Gloff > wrote: > >> I can confirm adding #include to test/egl_common.c gets past >> the original error, but then fails with: >> >> > thank you for checking :-) > > >> >> >> Log data follows: >> | DEBUG: Executing shell function do_compile >> | [1/2] Compiling c object 'test/glx_beginend@exe/glx_beginend.c.o' >> | [2/2] Linking target test/glx_beginend >> | FAILED: test/glx_beginend >> | arm-poky-linux-gnueabi-gcc -o test/glx_beginend 'test/glx_beginend@exe >> /glx_beginend.c.o' '-Wl,--no-undefined' '-Wl,--as-needed' '-O2' '-pipe' >> '-g' '-feliminate-unused-debug-types' '-fdebug-prefix-map=/home/mich >> ael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4- >> poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0' >> '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/tmp/ >> work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot-native=' >> '-fdebug-prefix-map=/home/michael/oe/recipes/rpi-build/tmp/ >> work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot=' >> '-Wl,-O1' '-Wl,--hash-style=gnu' '-Wl,--as-needed' 'test/libglx_common.a' >> 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' 'src/libepoxy.so.0.0.0' >> '-ldl' '-lX11' '-ldl' '-Wl,-rpath,/home/michael/oe/r >> ecipes/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux- >> gnueabi/libepoxy/1.4.3-r0/build/src' -march=armv7ve -marm >> -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 >> --sysroot=/home/michael/oe/recipes/rpi-build/tmp/work/cortex >> a7hf-neon-vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot >> -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed >> | test/glx_beginend@exe/glx_beginend.c.o: In function >> `test_without_epoxy': >> | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:70: >> undefined reference to `glBegin' >> | /usr/src/debug/libepoxy/1.4.3-r0/libepoxy-1.4.3/test/glx_beginend.c:85: >> undefined reference to `glEnd' >> | collect2: error: ld returned 1 exit status >> | ninja: build stopped: subcommand failed. >> | WARNING: /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon- >> vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/run.do_compile.2610:1 >> exit 1 from 'ninja -j 8' >> | ERROR: Function failed: do_compile (log file is located at >> /home/michael/oe/recipes/rpi-build/tmp/work/cortexa7hf-neon- >> vfpv4-poky-linux-gnueabi/libepoxy/1.4.3-r0/temp/log.do_compile.2610) >> ERROR: Task (/home/michael/oe/recipes/poky/meta/recipes-graphics/libepox >> y/libepoxy_1.4.3.bb:do_compile) failed with exit code '1' >> >> > that suggests a missing #include > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern in remove_alt
From: Jackie Huang
'\>' is to matches the end of a word, but the executable is
not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[
then such alternatives can not be removed.
So change to use '\s' in the pattern since the following
character of the $path is whitespace.
Signed-off-by: Jackie Huang
---
update-alternatives | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/update-alternatives b/update-alternatives
index ffad853..ce7d66c 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -80,7 +80,7 @@ remove_alt() {
[ ! -f $ad/$name ] && return 0
path=`echo $path | protect_slashes | protect_special_character`
- sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
+ sed -ne "/^$path\s.*/!p" $ad/$name > $ad/$name.new
mv $ad/$name.new $ad/$name
}
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern in remove_alt
From: Jackie Huang
'\>' is to matches the end of a word, but the executable is
not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[
then such alternatives can not be removed.
So change to use '\s' in the pattern since the following
character of the $path is whitespace.
Signed-off-by: Jackie Huang
---
update-alternatives | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/update-alternatives b/update-alternatives
index ffad853..ce7d66c 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -80,7 +80,7 @@ remove_alt() {
[ ! -f $ad/$name ] && return 0
path=`echo $path | protect_slashes | protect_special_character`
- sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
+ sed -ne "/^$path\s.*/!p" $ad/$name > $ad/$name.new
mv $ad/$name.new $ad/$name
}
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern in remove_alt
Sorry I forgot adding opkg-devel, so I just re-sent with opkg-devel added in.
Thanks,
Jackie
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Friday, January 19, 2018 10:54
> To: yocto@yoctoproject.org
> Subject: [yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern
> in
> remove_alt
>
> From: Jackie Huang
>
> '\>' is to matches the end of a word, but the executable is
> not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[
>
> then such alternatives can not be removed.
>
> So change to use '\s' in the pattern since the following
> character of the $path is whitespace.
>
> Signed-off-by: Jackie Huang
> ---
> update-alternatives | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/update-alternatives b/update-alternatives
> index ffad853..ce7d66c 100644
> --- a/update-alternatives
> +++ b/update-alternatives
> @@ -80,7 +80,7 @@ remove_alt() {
> [ ! -f $ad/$name ] && return 0
>
> path=`echo $path | protect_slashes | protect_special_character`
> - sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
> + sed -ne "/^$path\s.*/!p" $ad/$name > $ad/$name.new
> mv $ad/$name.new $ad/$name
> }
>
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On Thu, Jan 18, 2018 at 5:49 AM, Alexander Kanavin wrote: > On 01/18/2018 03:41 PM, Andrea Galbusera wrote: >> >> Yes, this is coherent with what Alexander's commit message says. We >> started building stuff in test/ while switching to meson... >> If we can't easily fix the upstream ourself and/or reproduce outside >> of OE to ask for help from upstream devels, IMO we should temporarily >> prevent meson from building the tests. > > Note that this same test does build fine in poky, so disabling the tests is > not a good fix. You should figure out what is about the non-poky EGL headers > that is causing the failure, and whether you need to configure the provider > of those headers differently, or add missing dependencies etc. Upstream documents that the test suite relies on X11: https://github.com/anholt/libepoxy/blob/1.4.3/README.md#building So disabling the test suite for targets without X11 seems like a perfectly reasonable approach. > Alex > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Automated license incompatibility checks
Hi, I was looking for a way to analyze in more detail how packages of different licenses was used in an image, and stumbled upon this old mail-thread: https://lists.yoctoproject.org/pipermail/yocto/2015-January/023307.html My end goal is pretty much the same as Clemens, that I want to be able to have checks/rules for which licenses are ok to have when linking dynamically/statically to other libraries. Does anyone know if this work ever got published somewhere? It seems like a very nice functionality to have. Cheers, Erik -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Pyro] Multiple toolchains
2018-01-17 17:11 GMT+01:00 Herman van Hazendonk : > Hi Philippe, > > You might want to try to patch your kernel for newer GCC versions. We've > done that successfully with our 3.4 based kernels. See for example the > commits we used on our LG Hammerhead (Nexus 5) kernel. > https://github.com/Halium/android_kernel_lge_hammerhead/commits/halium-5.1 > See the commits from 13th of October for reference. There are other ways to > do it and have separate toolchains, but that should address your main GCC > related issues probably. > Herman, Thank you for your tip. I actually managed to compile our kernel with the 5.x toolchain using: 1. your patch https://github.com/Halium/android_kernel_lge_hammerhead/commit/af33db048d85d789410e2c1fa44aa5fca187c777 2. had to specify in our recipe the C Dialect to gnu89 (see: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/C-Dialect-Options.html#C-Dialect-Options) with: KERNEL_EXTRA_ARGS += " KCFLAGS=-std=gnu89 " It might also work with the 6.x using the compile-gcc6.h header -- Philippe GISLARD -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
On 01/19/2018 05:29 AM, Andre McCurdy wrote: Note that this same test does build fine in poky, so disabling the tests is not a good fix. You should figure out what is about the non-poky EGL headers that is causing the failure, and whether you need to configure the provider of those headers differently, or add missing dependencies etc. Upstream documents that the test suite relies on X11: https://github.com/anholt/libepoxy/blob/1.4.3/README.md#building So disabling the test suite for targets without X11 seems like a perfectly reasonable approach. The meson.build files already have guards for lack of X11 around the test files that are failing here. It looks like in this particular configuration meson erroneously detects that X11 is present, when it's not. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
