Error do_compile libepoxy

Error do_compile libepoxy

[Mathias Rudnik]

[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]

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 <http://lists.openembedded.org/mailman/listinfo/openembedded-core>' '-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 <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/egl_common.c.o' '-MF' 'test/egl_common at sta <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/egl_common.c.o.d' -o 'test/egl_common at sta <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/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?

[-- Attachment #2: Type: text/html, Size: 3365 bytes --]

Re: Error do_compile libepoxy

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]

I suggest you ask the upstream maintainers of libepoxy.

Ross

On 17 January 2018 at 12:46, Mathias Rudnik <rudnik.mathias@googlemail.com>
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 <http://lists.openembedded.org/mailman/listinfo/openembedded-core>' '-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 <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/egl_common.c.o' '-MF' 'test/egl_common at sta <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/egl_common.c.o.d' -o 'test/egl_common at sta <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/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?
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 4649 bytes --]

Re: Error do_compile libepoxy

[Andrea Galbusera]

Hi!

On Wed, Jan 17, 2018 at 1:46 PM, Mathias Rudnik
<rudnik.mathias@googlemail.com> 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.

Re: Error do_compile libepoxy

[Andrea Galbusera]

On Wed, Jan 17, 2018 at 1:58 PM, Andrea Galbusera <gizero@gmail.com> wrote:
> Hi!
>
> On Wed, Jan 17, 2018 at 1:46 PM, Mathias Rudnik
> <rudnik.mathias@googlemail.com> 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 <alexander.kanavin@linux.intel.com>
AuthorDate: Thu Jan 4 15:12:33 2018 +0200
Commit:     Richard Purdie <richard.purdie@linuxfoundation.org>
CommitDate: Fri Jan 5 12:02:37 2018 +0000

    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 <alexander.kanavin@linux.intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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:071abd63f0d35c194288bf590f252ee3cf039cc7"

Re: Error do_compile libepoxy

[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.


Alex

Re: Error do_compile libepoxy

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2267 bytes --]

Re: Error do_compile libepoxy

[Alexander Kanavin]

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

Re: Error do_compile libepoxy

[Max Krummenacher]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

Hi

2018-01-18 10:05 GMT+01:00 Alexander Kanavin <
alexander.kanavin@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.000000000 +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

[-- Attachment #2: Type: text/html, Size: 2501 bytes --]

Re: Error do_compile libepoxy

[Andrea Galbusera]

On Thu, Jan 18, 2018 at 2:13 PM, Max Krummenacher <max.oss.09@gmail.com> wrote:
> Hi
>
> 2018-01-18 10:05 GMT+01:00 Alexander Kanavin
> <alexander.kanavin@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.000000000 +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.

Re: Error do_compile libepoxy

[Alexander Kanavin]

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

Re: Error do_compile libepoxy

[Andre McCurdy]

On Thu, Jan 18, 2018 at 5:49 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> 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

Re: Error do_compile libepoxy

[Alexander Kanavin]

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

Re: Error do_compile libepoxy

[Andrea Galbusera]

On Fri, Jan 19, 2018 at 8:45 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> 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

I'll try to recap a little bit but, please, forgive my ignorance in
graphics stacks and libraries.
Disclaimer: mostly working on headless systems... my bad!
This is what I think I understand here (remember I test building poky
+ meta-raspberrypi):
* libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
on virtual/X11 when this is available in DISTRO_FEATURE
* the latter is the case for poky which is the DISTRO I'm building
for. This gives i.e. a populated recipe-sysroot/usr/include/X11
* upstream meson.build conditionally builds tests if X11 is
available... so we expect they should build fine in this case
* compile fails on test/egl_common.c which does not explicitly include
X11/Xlib.h by itself. Doing so moves things forward but, to me, does
not seem to be the right thing to do.

Is this correct to assume that the upstream tested usecases are
probably getting the include otherwise, maybe conditionally as Alex
initially suggested. If so, where should we look for the missing
pieces?

Andrea

Re: Error do_compile libepoxy

[Alexander Kanavin]

> I'll try to recap a little bit but, please, forgive my ignorance in
> graphics stacks and libraries.
> Disclaimer: mostly working on headless systems... my bad!
> This is what I think I understand here (remember I test building poky
> + meta-raspberrypi):
> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
> on virtual/X11 when this is available in DISTRO_FEATURE
> * the latter is the case for poky which is the DISTRO I'm building
> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
> * upstream meson.build conditionally builds tests if X11 is
> available... so we expect they should build fine in this case
> * compile fails on test/egl_common.c which does not explicitly include
> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
> not seem to be the right thing to do.
> 
> Is this correct to assume that the upstream tested usecases are
> probably getting the include otherwise, maybe conditionally as Alex
> initially suggested. If so, where should we look for the missing
> pieces?

I'm similarly ignorant about this stuff (our resident graphics stack 
expert Jussi Kukkonen left a few months ago), but let's consider the 
build files:

- the offending tests are wrapped in "if build_egl and build_x11_tests"

- build_egl is controlled by a PACKAGECONFIG, and I guess you do have it 
available

- "build_x11_tests = build_glx and x11_dep.found()" - build_glx is 
similarly controlled by a PACKAGECONFIG, and enabled if x11 is in 
DISTRO_FEATURES:

PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"

This is where I think the configuration is not quite right. Instead of 
virtual/libx11, it should say virtual/libgl. And if that dependency 
cannot be satisfied, then the x11 option should be altogether disabled 
in the distro/local config (in poky mesa provides virtual/libgl). At 
least that's how it's configured in many other recipes throughout oe-core.

Can you try:
a) disabling x11 PACKAGECONFIG in your local config and see if things build?
b) changing the dependency in that option to virtual/libgl and see what 
kind of error you get, if any. I guess this is the right fix after all.

Alex

Re: Error do_compile libepoxy

[Andrea Galbusera]

On Fri, Jan 19, 2018 at 1:32 PM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
>
>> I'll try to recap a little bit but, please, forgive my ignorance in
>> graphics stacks and libraries.
>> Disclaimer: mostly working on headless systems... my bad!
>> This is what I think I understand here (remember I test building poky
>> + meta-raspberrypi):
>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>> on virtual/X11 when this is available in DISTRO_FEATURE
>> * the latter is the case for poky which is the DISTRO I'm building
>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>> * upstream meson.build conditionally builds tests if X11 is
>> available... so we expect they should build fine in this case
>> * compile fails on test/egl_common.c which does not explicitly include
>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>> not seem to be the right thing to do.
>>
>> Is this correct to assume that the upstream tested usecases are
>> probably getting the include otherwise, maybe conditionally as Alex
>> initially suggested. If so, where should we look for the missing
>> pieces?
>
>
> I'm similarly ignorant about this stuff (our resident graphics stack expert
> Jussi Kukkonen left a few months ago), but let's consider the build files:

Yes! Jussi helped a lot in the past with issues raised by graphic
recipes from meta-raspberrypi, most notably 'userland' (see below)...

> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>
> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
> available

Yes, if I understand correctly, meta-raspberrypi uses either 'mesa' or
'userland' [1]
as providers for virtual/egl, mesa being chosen only for 64bit builds
of raspberrypi3.

PREFERRED_PROVIDER_virtual/egl ?=
"${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa",
"userland", d)}"

BTW I gave the 64bit a spin right now to see if something changed with
mesa instead of userland... and it turned out to build just fine
(tests included).
Nailing it down to something userland is supposed to provide but does
not as expected?

[1] https://github.com/raspberrypi/userland

> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is similarly
> controlled by a PACKAGECONFIG, and enabled if x11 is in DISTRO_FEATURES:
>
> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>
> This is where I think the configuration is not quite right. Instead of
> virtual/libx11, it should say virtual/libgl. And if that dependency cannot
> be satisfied, then the x11 option should be altogether disabled in the
> distro/local config (in poky mesa provides virtual/libgl). At least that's
> how it's configured in many other recipes throughout oe-core.

Can you point to any in particular so I can have a look at the pattern?

> Can you try:
> a) disabling x11 PACKAGECONFIG in your local config and see if things build?

Yes, they do. As expected, meson does not find the X11 dependency and
skips building tests...

> b) changing the dependency in that option to virtual/libgl and see what kind
> of error you get, if any. I guess this is the right fix after all.

Nope, below change has no effect. The error is the same as in the
original post (missing symbols from X11/Xlib.h)

diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index 72167a2..ee9db24 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -20,7 +20,7 @@ REQUIRED_DISTRO_FEATURES = "opengl"
 DEPENDS = "util-macros"

 PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
-PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
+PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"

 EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "

Re: Error do_compile libepoxy

[Alexander Kanavin]

On 01/19/2018 06:36 PM, Andrea Galbusera wrote:

>> This is where I think the configuration is not quite right. Instead of
>> virtual/libx11, it should say virtual/libgl. And if that dependency cannot
>> be satisfied, then the x11 option should be altogether disabled in the
>> distro/local config (in poky mesa provides virtual/libgl). At least that's
>> how it's configured in many other recipes throughout oe-core.
> 
> Can you point to any in particular so I can have a look at the pattern?

Basically anything that mentions 'virtual/libgl' - you can grep the 
oe-core layer for it.

>> b) changing the dependency in that option to virtual/libgl and see what kind
>> of error you get, if any. I guess this is the right fix after all.
> 
> Nope, below change has no effect. The error is the same as in the
> original post (missing symbols from X11/Xlib.h)

Before producing any patches, I'd really like you to establish the 
difference between working and failing build in a systematic way - we've 
all been doing 'shotgun debugging based on guessing' up to now to be 
honest. Here's how:

1. Do not make any changes to libepoxy recipe, use it as it is now in 
oe-core.

2. Build libepoxy with a default plain-poky config, it should succeed. 
Copy the working directory of libepoxy somewhere safe for later comparison.

3. Build libepoxy with raspberry config that makes it fail.

4. Carefully compare the working directory of libepoxy with the one that 
you saved. What are the differences? How do the configure and compile 
steps differ (particularly the output of meson at do_configure stage, 
ninja build files, and compiler flags)? How do the sysroots differ, 
particularly in what gets installed to /usr/include? It would be great 
to establish the specific root cause of the failure vs success and work 
out a fix from there.

Alex

Re: Error do_compile libepoxy

[Anuj Mittal]

On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
> 
>> I'll try to recap a little bit but, please, forgive my ignorance in
>> graphics stacks and libraries.
>> Disclaimer: mostly working on headless systems... my bad!
>> This is what I think I understand here (remember I test building poky
>> + meta-raspberrypi):
>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>> on virtual/X11 when this is available in DISTRO_FEATURE
>> * the latter is the case for poky which is the DISTRO I'm building
>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>> * upstream meson.build conditionally builds tests if X11 is
>> available... so we expect they should build fine in this case
>> * compile fails on test/egl_common.c which does not explicitly include
>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>> not seem to be the right thing to do.
>>
>> Is this correct to assume that the upstream tested usecases are
>> probably getting the include otherwise, maybe conditionally as Alex
>> initially suggested. If so, where should we look for the missing
>> pieces?
> 
> I'm similarly ignorant about this stuff (our resident graphics stack 
> expert Jussi Kukkonen left a few months ago), but let's consider the 
> build files:
> 
> - the offending tests are wrapped in "if build_egl and build_x11_tests"
> 
> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it 
> available
> 
> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is 
> similarly controlled by a PACKAGECONFIG, and enabled if x11 is in 
> DISTRO_FEATURES:
> 
> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
> 
> This is where I think the configuration is not quite right. Instead of 
> virtual/libx11, it should say virtual/libgl. And if that dependency 
> cannot be satisfied, then the x11 option should be altogether disabled 
> in the distro/local config (in poky mesa provides virtual/libgl). At 
> least that's how it's configured in many other recipes throughout oe-core.
> 
> Can you try:
> a) disabling x11 PACKAGECONFIG in your local config and see if things build?
> b) changing the dependency in that option to virtual/libgl and see what 
> kind of error you get, if any. I guess this is the right fix after all.

Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
glx depends on gl and x11 so if it is to be enabled, both of them should
be present.

However, x11 without glx and just egl should still be valid configuration.

I think the correct configuration should be:


diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index 72167a2..0043bec 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
"https://github.com/anholt/libepoxy/releases"

 inherit meson pkgconfig distro_features_check

-REQUIRED_DISTRO_FEATURES = "opengl"
-
 DEPENDS = "util-macros"

+REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
'glx', 'x11', '', d)}"
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \
+                   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'egl', '', d)}"
+
 PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
-PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
+PACKAGECONFIG[glx] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
+PACKAGECONFIG[x11] = ",, virtual/libx11"

 EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "

I didn't test this on all combinations. Perhaps someone can help test on
rpi?


> 
> Alex
> 

Re: Error do_compile libepoxy

[Andrea Galbusera]

On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal <anuj.mittal@intel.com> wrote:
> On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
>>
>>> I'll try to recap a little bit but, please, forgive my ignorance in
>>> graphics stacks and libraries.
>>> Disclaimer: mostly working on headless systems... my bad!
>>> This is what I think I understand here (remember I test building poky
>>> + meta-raspberrypi):
>>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>>> on virtual/X11 when this is available in DISTRO_FEATURE
>>> * the latter is the case for poky which is the DISTRO I'm building
>>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>>> * upstream meson.build conditionally builds tests if X11 is
>>> available... so we expect they should build fine in this case
>>> * compile fails on test/egl_common.c which does not explicitly include
>>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>>> not seem to be the right thing to do.
>>>
>>> Is this correct to assume that the upstream tested usecases are
>>> probably getting the include otherwise, maybe conditionally as Alex
>>> initially suggested. If so, where should we look for the missing
>>> pieces?
>>
>> I'm similarly ignorant about this stuff (our resident graphics stack
>> expert Jussi Kukkonen left a few months ago), but let's consider the
>> build files:
>>
>> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>>
>> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
>> available
>>
>> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is
>> similarly controlled by a PACKAGECONFIG, and enabled if x11 is in
>> DISTRO_FEATURES:
>>
>> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>>
>> This is where I think the configuration is not quite right. Instead of
>> virtual/libx11, it should say virtual/libgl. And if that dependency
>> cannot be satisfied, then the x11 option should be altogether disabled
>> in the distro/local config (in poky mesa provides virtual/libgl). At
>> least that's how it's configured in many other recipes throughout oe-core.
>>
>> Can you try:
>> a) disabling x11 PACKAGECONFIG in your local config and see if things build?
>> b) changing the dependency in that option to virtual/libgl and see what
>> kind of error you get, if any. I guess this is the right fix after all.
>
> Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
> glx depends on gl and x11 so if it is to be enabled, both of them should
> be present.
>
> However, x11 without glx and just egl should still be valid configuration.
>
> I think the correct configuration should be:
>
>
> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> index 72167a2..0043bec 100644
> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> @@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
> "https://github.com/anholt/libepoxy/releases"
>
>  inherit meson pkgconfig distro_features_check
>
> -REQUIRED_DISTRO_FEATURES = "opengl"
> -
>  DEPENDS = "util-macros"
>
> +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
> 'glx', 'x11', '', d)}"
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \

Did you mean 'opengl x11' or is glx a valid distro feature? I don't
see it mentioned anywhere else...

> +                   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'egl', '', d)}"
> +
>  PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
> -PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
> +PACKAGECONFIG[glx] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
> +PACKAGECONFIG[x11] = ",, virtual/libx11"
>
>  EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "
>
> I didn't test this on all combinations. Perhaps someone can help test on
> rpi?

Thanks, I volunteer to keep testing with rpi configurations, but I
don't understand the realm enough to judge the patch effect on other
scenarios.

Re: Error do_compile libepoxy

[Anuj Mittal]

On 01/21/2018 01:07 AM, Andrea Galbusera wrote:
> On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal <anuj.mittal@intel.com> wrote:
>> On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
>>>
>>>> I'll try to recap a little bit but, please, forgive my ignorance in
>>>> graphics stacks and libraries.
>>>> Disclaimer: mostly working on headless systems... my bad!
>>>> This is what I think I understand here (remember I test building poky
>>>> + meta-raspberrypi):
>>>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>>>> on virtual/X11 when this is available in DISTRO_FEATURE
>>>> * the latter is the case for poky which is the DISTRO I'm building
>>>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>>>> * upstream meson.build conditionally builds tests if X11 is
>>>> available... so we expect they should build fine in this case
>>>> * compile fails on test/egl_common.c which does not explicitly include
>>>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>>>> not seem to be the right thing to do.
>>>>
>>>> Is this correct to assume that the upstream tested usecases are
>>>> probably getting the include otherwise, maybe conditionally as Alex
>>>> initially suggested. If so, where should we look for the missing
>>>> pieces?
>>>
>>> I'm similarly ignorant about this stuff (our resident graphics stack
>>> expert Jussi Kukkonen left a few months ago), but let's consider the
>>> build files:
>>>
>>> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>>>
>>> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
>>> available
>>>
>>> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is
>>> similarly controlled by a PACKAGECONFIG, and enabled if x11 is in
>>> DISTRO_FEATURES:
>>>
>>> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>>> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>>>
>>> This is where I think the configuration is not quite right. Instead of
>>> virtual/libx11, it should say virtual/libgl. And if that dependency
>>> cannot be satisfied, then the x11 option should be altogether disabled
>>> in the distro/local config (in poky mesa provides virtual/libgl). At
>>> least that's how it's configured in many other recipes throughout oe-core.
>>>
>>> Can you try:
>>> a) disabling x11 PACKAGECONFIG in your local config and see if things build?
>>> b) changing the dependency in that option to virtual/libgl and see what
>>> kind of error you get, if any. I guess this is the right fix after all.
>>
>> Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
>> glx depends on gl and x11 so if it is to be enabled, both of them should
>> be present.
>>
>> However, x11 without glx and just egl should still be valid configuration.
>>
>> I think the correct configuration should be:
>>
>>
>> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> index 72167a2..0043bec 100644
>> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> @@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
>> "https://github.com/anholt/libepoxy/releases"
>>
>>  inherit meson pkgconfig distro_features_check
>>
>> -REQUIRED_DISTRO_FEATURES = "opengl"
>> -
>>  DEPENDS = "util-macros"
>>
>> +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
>> 'glx', 'x11', '', d)}"
>> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \
> 
> Did you mean 'opengl x11' or is glx a valid distro feature? I don't
> see it mentioned anywhere else...

Oh yes, you're right. I was trying something out & didn't clean before
sending. It should be:

bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', d)

However, I think it'll probably still fail for rpi because I think this
test depends on Xlib.h being included from EGL/eglplatform.h but in case
of "userland", doesn't happen because that include is probably not there.

Can you try an explicit include of Xlib.h in egl_common.c after patching
this recipe? You shouldn't get the GL linking errors after that since we
have now added explicit dependency on virtual/libgl when glx is enabled.

> 
>> +                   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
>> 'egl', '', d)}"
>> +
>>  PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
>> -PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>> +PACKAGECONFIG[glx] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
>> +PACKAGECONFIG[x11] = ",, virtual/libx11"
>>
>>  EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "
>>
>> I didn't test this on all combinations. Perhaps someone can help test on
>> rpi?
> 
> Thanks, I volunteer to keep testing with rpi configurations, but I
> don't understand the realm enough to judge the patch effect on other
> scenarios.
> 

Re: Error do_compile libepoxy

[Andrea Galbusera]

Hi Anuj,

On Sun, Jan 21, 2018 at 4:23 PM, Anuj Mittal <anuj.mittal@intel.com> wrote:
> On 01/21/2018 01:07 AM, Andrea Galbusera wrote:
>> On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal <anuj.mittal@intel.com> wrote:
>>> On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
>>>>
>>>>> I'll try to recap a little bit but, please, forgive my ignorance in
>>>>> graphics stacks and libraries.
>>>>> Disclaimer: mostly working on headless systems... my bad!
>>>>> This is what I think I understand here (remember I test building poky
>>>>> + meta-raspberrypi):
>>>>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>>>>> on virtual/X11 when this is available in DISTRO_FEATURE
>>>>> * the latter is the case for poky which is the DISTRO I'm building
>>>>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>>>>> * upstream meson.build conditionally builds tests if X11 is
>>>>> available... so we expect they should build fine in this case
>>>>> * compile fails on test/egl_common.c which does not explicitly include
>>>>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>>>>> not seem to be the right thing to do.
>>>>>
>>>>> Is this correct to assume that the upstream tested usecases are
>>>>> probably getting the include otherwise, maybe conditionally as Alex
>>>>> initially suggested. If so, where should we look for the missing
>>>>> pieces?
>>>>
>>>> I'm similarly ignorant about this stuff (our resident graphics stack
>>>> expert Jussi Kukkonen left a few months ago), but let's consider the
>>>> build files:
>>>>
>>>> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>>>>
>>>> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
>>>> available
>>>>
>>>> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is
>>>> similarly controlled by a PACKAGECONFIG, and enabled if x11 is in
>>>> DISTRO_FEATURES:
>>>>
>>>> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>>>> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>>>>
>>>> This is where I think the configuration is not quite right. Instead of
>>>> virtual/libx11, it should say virtual/libgl. And if that dependency
>>>> cannot be satisfied, then the x11 option should be altogether disabled
>>>> in the distro/local config (in poky mesa provides virtual/libgl). At
>>>> least that's how it's configured in many other recipes throughout oe-core.
>>>>
>>>> Can you try:
>>>> a) disabling x11 PACKAGECONFIG in your local config and see if things build?
>>>> b) changing the dependency in that option to virtual/libgl and see what
>>>> kind of error you get, if any. I guess this is the right fix after all.
>>>
>>> Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
>>> glx depends on gl and x11 so if it is to be enabled, both of them should
>>> be present.
>>>
>>> However, x11 without glx and just egl should still be valid configuration.
>>>
>>> I think the correct configuration should be:
>>>
>>>
>>> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> index 72167a2..0043bec 100644
>>> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> @@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
>>> "https://github.com/anholt/libepoxy/releases"
>>>
>>>  inherit meson pkgconfig distro_features_check
>>>
>>> -REQUIRED_DISTRO_FEATURES = "opengl"
>>> -
>>>  DEPENDS = "util-macros"
>>>
>>> +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
>>> 'glx', 'x11', '', d)}"
>>> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \
>>
>> Did you mean 'opengl x11' or is glx a valid distro feature? I don't
>> see it mentioned anywhere else...
>
> Oh yes, you're right. I was trying something out & didn't clean before
> sending. It should be:
>
> bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', d)
>
> However, I think it'll probably still fail for rpi because I think this
> test depends on Xlib.h being included from EGL/eglplatform.h but in case
> of "userland", doesn't happen because that include is probably not there.
>
> Can you try an explicit include of Xlib.h in egl_common.c after patching
> this recipe? You shouldn't get the GL linking errors after that since we
> have now added explicit dependency on virtual/libgl when glx is enabled.

The updated patch seems to work here! libepoxy builds fine along with
tests for raspberrypi3 default configs. All my build turned back to
green. A cascaded failure on gtk+3 I was seeing with the previous
version of your patch went away. Of course, I had to explicitly
include the Xlib.h as you suggested to get past the compile error.
EGL/eglplatform.h from userland has already been causing issues with
missing declarations in the past (see [1] and [2] for some context).
Once more, looking at Khronos registry [3], which I learned being the
right upstream reference for such an header, expected X11 includes are
there, while, as said, they are missing in userland eglplatform.h.
Unfortunately userland community does not seem to be very keen to
update their includes even though Khronos published more up to date
versions. I'll try to follow up with a patch to meta-raspberrypi and
possibly upstream to userland. In the end, I don't think libepoxy is
the right place to explicitly put the change. What's your opinion
here?

I don't have other builds with graphics stacks enabled at hand that I
can test your patch against. Do you think further testing will be
needed before you can submit this patch to oe-core?

[1] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg98209.html
[2] https://github.com/raspberrypi/userland/pull/407
[3] https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h

>
>>
>>> +                   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
>>> 'egl', '', d)}"
>>> +
>>>  PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
>>> -PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>>> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>>> +PACKAGECONFIG[glx] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
>>> +PACKAGECONFIG[x11] = ",, virtual/libx11"
>>>
>>>  EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "
>>>
>>> I didn't test this on all combinations. Perhaps someone can help test on
>>> rpi?
>>
>> Thanks, I volunteer to keep testing with rpi configurations, but I
>> don't understand the realm enough to judge the patch effect on other
>> scenarios.
>>
>

Re: Error do_compile libepoxy

[Trevor Woerner]

On Mon 2018-01-22 @ 10:12:27 AM, Andrea Galbusera wrote:
> I'll try to follow up with a patch to meta-raspberrypi and
> possibly upstream to userland. In the end, I don't think libepoxy is
> the right place to explicitly put the change. What's your opinion
> here?

If I write C code, and in one of my C source files I use the function
XOpenDisplay(), then I'm of the opinion that (to be correct) this source file
should also #include <X11/Xlib.h> directly, and not depend on X11/Xlib.h being
included as a by-product of some other #include somewhere randomly up the
chain.

On the other hand, if I call function xyz() (and therefore #include <xyz.h>)
and xyz() calls XOpenDisplay(), then I would expect xyz.h to #include
<X11/Xlib.h> and not expect me to track down the header file for
XOpenDisplay() myself.

In my opinion the libepoxy code would be the right place to correct the
missing header file if it is calling XOpenDisplay() directly.

> Once more, looking at Khronos registry [3], which I learned being the
> right upstream reference for such an header, expected X11 includes are
> there, while, as said, they are missing in userland eglplatform.h.
> Unfortunately userland community does not seem to be very keen to
> update their includes even though Khronos published more up to date
> versions.
> 
> [3] https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h

If you follow that link, the Xlib #includes in that very file are marked
"tentative"! Therefore I think the userland people can be excused from not
jumping on a request to add them.

Besides, let's say we don't add the #include to libepoxy and get the userland
people to add it in their header, then, 6 months later, Khronos votes on this
"tentative" issue and decides not to include them. userland would then remove
them from its headers, and we'd be right back where we are now: with C code
that uses a function but doesn't also include its relevant header directly.

Re: Error do_compile libepoxy

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Thu, Jan 18, 2018 at 4:05 AM, Alexander Kanavin <
alexander.kanavin@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 <X11/Xlib.h>

[-- Attachment #2: Type: text/html, Size: 1587 bytes --]

Re: Error do_compile libepoxy

[Michael Gloff]

[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]

I can confirm adding #include <X11/Xlib.h> 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 <twoerner@gmail.com> wrote:

> On Thu, Jan 18, 2018 at 4:05 AM, Alexander Kanavin <
> alexander.kanavin@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 <X11/Xlib.h>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 4999 bytes --]

Re: Error do_compile libepoxy

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]

On Thu, Jan 18, 2018 at 10:05 AM, Michael Gloff <mgloff@emacinc.com> wrote:

> I can confirm adding #include <X11/Xlib.h> 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 <GL/gl.h>

[-- Attachment #2: Type: text/html, Size: 3572 bytes --]

Re: Error do_compile libepoxy

[Michael Gloff]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

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 <twoerner@gmail.com> wrote:

> On Thu, Jan 18, 2018 at 10:05 AM, Michael Gloff <mgloff@emacinc.com>
> wrote:
>
>> I can confirm adding #include <X11/Xlib.h> 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 <GL/gl.h>
>

[-- Attachment #2: Type: text/html, Size: 4240 bytes --]

Re: Error do_compile libepoxy

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On 18 January 2018 at 08:58, Andrea Galbusera <gizero@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 756 bytes --]

Error do_compile libepoxy

[Mathias Rudnik]

[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]

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 <http://lists.openembedded.org/mailman/listinfo/openembedded-core>' '-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 <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/egl_common.c.o' '-MF' 'test/egl_common at sta <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/egl_common.c.o.d' -o 'test/egl_common at sta <http://lists.openembedded.org/mailman/listinfo/openembedded-core>/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?

[-- Attachment #2: Type: text/html, Size: 3365 bytes --]

Error do_compile libepoxy

[Mathias Rudnik]

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@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@sta/egl_common.c.o' '-MF' 'test/egl_common@sta/egl_common.c.o.d' -o 'test/egl_common@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?

Re: Error do_compile libepoxy

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 3189 bytes --]

On Thu, Jan 11, 2018 at 2:18 PM, Mathias Rudnik <
rudnik.mathias@googlemail.com> 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@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@sta/egl_common.c.o' '-MF'
> 'test/egl_common@sta/egl_common.c.o.d' -o 'test/egl_common@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?
>


I've been seeing the same failure for the last 10 days or so on my nightly
rpi3-32 builds.

A quick, superficial, glance at the problem looks like a code issue; I'm
guessing a missing "#include <X11/Xlib.h>". If I find some time I'll take a
stab at it.

[-- Attachment #2: Type: text/html, Size: 4220 bytes --]