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
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 me
Hi Anuj,
On Sun, Jan 21, 2018 at 4:23 PM, Anuj Mittal wrote:
> On 01/21/2018 01:07 AM, Andrea Galbusera wrote:
>> On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal wrote:
>>> On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
> I'll try to recap a little bit but, please, forgive my ignorance
On 01/21/2018 01:07 AM, Andrea Galbusera wrote:
> On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal 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 workin
On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal 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 thi
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
>> + met
On Fri, Jan 19, 2018 at 1: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
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
On Fri, Jan 19, 2018 at 8:45 AM, Alexander Kanavin
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
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 differ
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
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 Woer
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 't
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_beg
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.
>> Al
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 s
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
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-in
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/sanitycheck
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/De
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
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 Me
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
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
I suggest you ask the upstream maintainers of libepoxy.
Ross
On 17 January 2018 at 12:46, 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 -mflo
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-li
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-li
27 matches
Mail list logo
