* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2017-02-14 14:51 ` Peter Korsgaard
2017-02-14 15:10 ` Thomas Petazzoni
2017-02-14 15:44 ` Philippe Proulx
` (7 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 14:51 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> arm | synergy-1.3.1 | NOK | http://autobuild.buildroot.net/results/d9ab699ba314f87a12b4982811ebfa1c3186a408
> CConfig.cpp: In member function 'CConfigReadContext::operator void*() const':
> CConfig.cpp:1851:9: error: cannot convert 'std::istream {aka std::basic_istream<char>}' to 'void*' in return
> Modern gcc issue ?
Yes, I believe so (this failures are with gcc 6.x). I had a quick look
yesterday, and our synergy package is ancient. It seems to have moved to
github and changed quite a bit since then.
https://github.com/symless/synergy/
The last release in the 1.3.x series is 1.3.8. I'll take a look and see
if that has fixed this issue.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 14:51 ` Peter Korsgaard
@ 2017-02-14 15:10 ` Thomas Petazzoni
2017-02-14 19:21 ` Peter Korsgaard
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 15:10 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 15:51:47 +0100, Peter Korsgaard wrote:
> Yes, I believe so (this failures are with gcc 6.x). I had a quick look
> yesterday, and our synergy package is ancient. It seems to have moved to
> github and changed quite a bit since then.
>
> https://github.com/symless/synergy/
>
> The last release in the 1.3.x series is 1.3.8. I'll take a look and see
> if that has fixed this issue.
See:
[PATCH 1/1] package/synergy: bump to version 1.8.5
on the mailing list. But that's a rather big update, with somewhat
scary things.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 15:10 ` Thomas Petazzoni
@ 2017-02-14 19:21 ` Peter Korsgaard
2017-02-14 20:03 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 19:21 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Tue, 14 Feb 2017 15:51:47 +0100, Peter Korsgaard wrote:
>> Yes, I believe so (this failures are with gcc 6.x). I had a quick look
>> yesterday, and our synergy package is ancient. It seems to have moved to
>> github and changed quite a bit since then.
>>
>> https://github.com/symless/synergy/
>>
>> The last release in the 1.3.x series is 1.3.8. I'll take a look and see
>> if that has fixed this issue.
> See:
> [PATCH 1/1] package/synergy: bump to version 1.8.5
> on the mailing list. But that's a rather big update, with somewhat
> scary things.
Ahh yes. I was looking for something smaller/less risky for 2017.02
though.
I see this patch is marked as rejected. Do you know why/by who?
https://patchwork.ozlabs.org/patch/703714/
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 19:21 ` Peter Korsgaard
@ 2017-02-14 20:03 ` Thomas Petazzoni
2017-02-14 20:21 ` Peter Korsgaard
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 20:03 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 20:21:16 +0100, Peter Korsgaard wrote:
> Ahh yes. I was looking for something smaller/less risky for 2017.02
> though.
Yes, indeed something smaller/less risky would be nice.
> I see this patch is marked as rejected. Do you know why/by who?
>
> https://patchwork.ozlabs.org/patch/703714/
I remember having a quick look at the patch, but since I didn't send a
review, I don't see why I would have marked it as Rejected. Could have
been just a mistake I guess.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 20:03 ` Thomas Petazzoni
@ 2017-02-14 20:21 ` Peter Korsgaard
0 siblings, 0 replies; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-14 20:21 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Tue, 14 Feb 2017 20:21:16 +0100, Peter Korsgaard wrote:
>> Ahh yes. I was looking for something smaller/less risky for 2017.02
>> though.
> Yes, indeed something smaller/less risky would be nice.
>> I see this patch is marked as rejected. Do you know why/by who?
>>
>> https://patchwork.ozlabs.org/patch/703714/
> I remember having a quick look at the patch, but since I didn't send a
> review, I don't see why I would have marked it as Rejected. Could have
> been just a mistake I guess.
Ok. I've changed it back to the "New" state again so we don't forget
about it.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-14 14:51 ` Peter Korsgaard
@ 2017-02-14 15:44 ` Philippe Proulx
2017-02-14 16:39 ` Yann E. MORIN
` (6 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Philippe Proulx @ 2017-02-14 15:44 UTC (permalink / raw)
To: buildroot
On Tue, Feb 14, 2017 at 8:27 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> J?rg, Peter, Romain, Bernd, Gustavo, Carsten, Philippe, Yann, Fran?ois,
> Dagg, Baruch and ARC/Synopsys developers, there are some questions for
> you below.
>
> Thanks!
>
[...]
> Philippe, could you have a look ?
>
> > arm | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/72e9a6f39bb8e4da421926d5a73911760777e93b
>
> Musl issue. Philippe, same thing :-)
Yes, I'll try to invest some time in BR this week.
Phil
[...]
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-14 14:51 ` Peter Korsgaard
2017-02-14 15:44 ` Philippe Proulx
@ 2017-02-14 16:39 ` Yann E. MORIN
2017-02-14 20:02 ` Thomas Petazzoni
2017-02-14 18:02 ` Baruch Siach
` (5 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Yann E. MORIN @ 2017-02-14 16:39 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-02-14 14:27 +0100, Thomas Petazzoni spake thusly:
> > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
>
> BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
>
> This seems like a quite messy configuration: we have mesa3d as the
> OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> what do you think about this?
I believe this case does not make sense. We should protect against that.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 16:39 ` Yann E. MORIN
@ 2017-02-14 20:02 ` Thomas Petazzoni
2017-02-14 20:05 ` Yann E. MORIN
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 20:02 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 17:39:27 +0100, Yann E. MORIN wrote:
> On 2017-02-14 14:27 +0100, Thomas Petazzoni spake thusly:
> > > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
> >
> > BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> > BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> > BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
> >
> > This seems like a quite messy configuration: we have mesa3d as the
> > OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> > what do you think about this?
>
> I believe this case does not make sense. We should protect against that.
Indeed. The question is how :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 20:02 ` Thomas Petazzoni
@ 2017-02-14 20:05 ` Yann E. MORIN
0 siblings, 0 replies; 25+ messages in thread
From: Yann E. MORIN @ 2017-02-14 20:05 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-02-14 21:02 +0100, Thomas Petazzoni spake thusly:
> On Tue, 14 Feb 2017 17:39:27 +0100, Yann E. MORIN wrote:
>
> > On 2017-02-14 14:27 +0100, Thomas Petazzoni spake thusly:
> > > > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
> > >
> > > BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> > > BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> > > BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
> > >
> > > This seems like a quite messy configuration: we have mesa3d as the
> > > OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> > > what do you think about this?
> >
> > I believe this case does not make sense. We should protect against that.
>
> Indeed. The question is how :-)
Working on it...
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2017-02-14 16:39 ` Yann E. MORIN
@ 2017-02-14 18:02 ` Baruch Siach
2017-02-14 19:37 ` Peter Korsgaard
2017-02-14 22:29 ` Thomas Petazzoni
` (4 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Baruch Siach @ 2017-02-14 18:02 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Tue, Feb 14, 2017 at 02:27:25PM +0100, Thomas Petazzoni wrote:
> > x86_64 | tcpreplay-4.1.2 | NOK | http://autobuild.buildroot.net/results/b3c31e803ff552a196ce5717372c09d6f64c91bf
>
> error: redefinition of 'struct ethhdr'
>
> I believe this has been fixed by the rebuild of the toolchains I
> deployed yesterday, which has the improvements done by Baruch. Baruch,
> could you confirm?
I confirmed the tcpreplay builds successfully with the newly built 2017.02-rc1
based x86-64-musl toolchain.
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (3 preceding siblings ...)
2017-02-14 18:02 ` Baruch Siach
@ 2017-02-14 22:29 ` Thomas Petazzoni
2017-02-15 7:38 ` Peter Korsgaard
2017-02-15 2:45 ` Sam Bobroff
` (3 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-14 22:29 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 14 Feb 2017 14:27:25 +0100, Thomas Petazzoni wrote:
> > arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/61bdfb7e0ff9628190d9eb86e40c4c90e768b8e2
> > arm | cbootimage-v1.7 | NOK | http://autobuild.buildroot.net/results/b78c03b85aef845ff57d499b40f52b476f8a760c
>
> Musl compatibility issue.
We merged a patch to disable cbootimage on musl.
> > i586 | cups-2.2.2 | NOK | http://autobuild.buildroot.net/results/486dea944d6ecba5c4e6e8ac664261c1909f4b4c
>
> The musl/i586/SSP issue.
I'm testing to simply disable SSP support with musl on i386. Will send
a patch shortly if that works.
> > powerpc | ddrescue-1.22 | NOK | http://autobuild.buildroot.net/results/4ac0754f1cc5ea934d6437e89d1f4906fb3fd0a8
>
> Missing <stdio.h> include in block.h I believe. Peter (Seiderer), could
> you send a patch to fix this?
Peter has sent a patch, and it was merged.
> > m68k | kmsxx-bd5f6471e619a6ba2987b... | NOK | http://autobuild.buildroot.net/results/2738e5fd446467b105f6dcca391500e3734e5a9b
>
> Missing magic gcc option, Waldemar will provide a fix.
Fixed by
https://git.buildroot.org/buildroot/commit/?id=82a935ae493b8159062c9c32b328c30ee130c5a8
> > sh4a | libraw-0.17.1 | NOK | http://autobuild.buildroot.net/results/908aef6c82d56060933713df217b6b2ba21a01b0
>
> error: 'SIZE_MAX' was not declared in this scope
>
> Missing header include I believe.
This one is annoying.
So libraw optionally depends on jasper, and it's when both are enabled
that the problem occurs.
The issue is that the jas_math.h header uses SIZE_MAX and other
definitions of <stdint.h>, but those definitions are not visible to C++
code, unless you define __STDC_LIMIT_MACROS.
So one would think "just define __STDC_LIMIT_MACROS before including
<stdint.h> in jas_math.h". Expect that libraw, before including jasper
headers, includes other headers that already include <stdint.h>. So by
the time jas_math.h includes <stdint.h>, it has already been included,
and therefore, the definition of __STDC_LIMIT_MACROS in jas_math.h has
no effect.
I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
of libraw would fix it, but it's rather weird to have this
implementation "detail" of jasper creep in all the way to users of the
library.
> > i586 | libv4l-1.12.2 | NOK | http://autobuild.buildroot.net/results/b8b96c7bbf2147dacac62485cbfdbcfd758271a5
>
> ir-ctl.o: In function `parse_opt':
> ir-ctl.c:(.text+0xb06): undefined reference to `strndupa'
> ir-ctl.o: In function `lirc_record':
> ir-ctl.c:(.text+0xe01): undefined reference to `TEMP_FAILURE_RETRY'
> ir-ctl.o: In function `main':
> ir-ctl.c:(.text.startup+0x9a): undefined reference to `TEMP_FAILURE_RETRY'
> ir-ctl.c:(.text.startup+0xd7): undefined reference to `TEMP_FAILURE_RETRY'
> ir-ctl.c:(.text.startup+0x64a): undefined reference to `TEMP_FAILURE_RETRY'
>
> Musl related, perhaps?
Fixed by Peter Seiderer.
> > arm | mesa3d-demos-8.3.0 | NOK | http://autobuild.buildroot.net/results/6f197c643972e92f0b27b3afac7da7b4b1115f7e
>
> BR2_PACKAGE_PROVIDES_LIBGL="mesa3d"
> BR2_PACKAGE_PROVIDES_LIBEGL="rpi-userland"
> BR2_PACKAGE_PROVIDES_LIBGLES="rpi-userland"
>
> This seems like a quite messy configuration: we have mesa3d as the
> OpenGL provider, and rpi-userland as the OpenGLES/EGL provider. Yann,
> what do you think about this?
Yann has submitted a proposal to fix this.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 22:29 ` Thomas Petazzoni
@ 2017-02-15 7:38 ` Peter Korsgaard
2017-02-15 8:33 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Peter Korsgaard @ 2017-02-15 7:38 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > sh4a | libraw-0.17.1 | NOK |
>> > http://autobuild.buildroot.net/results/908aef6c82d56060933713df217b6b2ba21a01b0
>>
>> error: 'SIZE_MAX' was not declared in this scope
>>
>> Missing header include I believe.
> This one is annoying.
> So libraw optionally depends on jasper, and it's when both are enabled
> that the problem occurs.
> The issue is that the jas_math.h header uses SIZE_MAX and other
> definitions of <stdint.h>, but those definitions are not visible to C++
> code, unless you define __STDC_LIMIT_MACROS.
> So one would think "just define __STDC_LIMIT_MACROS before including
> <stdint.h> in jas_math.h". Expect that libraw, before including jasper
> headers, includes other headers that already include <stdint.h>. So by
> the time jas_math.h includes <stdint.h>, it has already been included,
> and therefore, the definition of __STDC_LIMIT_MACROS in jas_math.h has
> no effect.
> I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
> of libraw would fix it, but it's rather weird to have this
> implementation "detail" of jasper creep in all the way to users of the
> library.
I didn't look at libraw yet, but couldn't the jasper include just be
moved to the top of the file?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 7:38 ` Peter Korsgaard
@ 2017-02-15 8:33 ` Thomas Petazzoni
2017-02-15 23:14 ` Arnout Vandecappelle
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-15 8:33 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 15 Feb 2017 08:38:07 +0100, Peter Korsgaard wrote:
> > I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
> > of libraw would fix it, but it's rather weird to have this
> > implementation "detail" of jasper creep in all the way to users of the
> > library.
>
> I didn't look at libraw yet, but couldn't the jasper include just be
> moved to the top of the file?
Haven't tried that. Could be an option, but it still seems weird.
However, I had a second thought about this: according to
http://autobuild.buildroot.net/?reason=libraw-0.17.1, we only have this
issue with toolchains using rather old gcc versions:
- SH4 toolchain is using 4.7
- the Buildroot i686/pentium4 toolchain is using gcc 4.5
- the older build results on Blackfin were with the Analog Devices
toolchain, gcc 4.3 based
With more recent toolchains (starting with gcc 4.8) this issue does not
occur. Is it something that has changed in the C/C++ standard
implemented starting from 4.8 ? Or is it C library version related ?
Indeed in the SH4 toolchain, the stdint.h header only provides the
SIZE_MAX and related definitions if you're *not* in C++ *or*
__STDC_LIMIT_MACROS is defined. But on my system, stdint.h doesn't have
anything like that: SIZE_MAX and related macros are unconditionally
defined.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 8:33 ` Thomas Petazzoni
@ 2017-02-15 23:14 ` Arnout Vandecappelle
2017-02-16 8:36 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Arnout Vandecappelle @ 2017-02-15 23:14 UTC (permalink / raw)
To: buildroot
On 15-02-17 09:33, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 15 Feb 2017 08:38:07 +0100, Peter Korsgaard wrote:
>
>> > I'm not sure how to fix this. Adding __STDC_LIMIT_MACROS to the build
>> > of libraw would fix it, but it's rather weird to have this
>> > implementation "detail" of jasper creep in all the way to users of the
>> > library.
>>
>> I didn't look at libraw yet, but couldn't the jasper include just be
>> moved to the top of the file?
>
> Haven't tried that. Could be an option, but it still seems weird.
>
> However, I had a second thought about this: according to
> http://autobuild.buildroot.net/?reason=libraw-0.17.1, we only have this
> issue with toolchains using rather old gcc versions:
>
> - SH4 toolchain is using 4.7
> - the Buildroot i686/pentium4 toolchain is using gcc 4.5
> - the older build results on Blackfin were with the Analog Devices
> toolchain, gcc 4.3 based
>
> With more recent toolchains (starting with gcc 4.8) this issue does not
> occur. Is it something that has changed in the C/C++ standard
> implemented starting from 4.8 ? Or is it C library version related ?
>
> Indeed in the SH4 toolchain, the stdint.h header only provides the
> SIZE_MAX and related definitions if you're *not* in C++ *or*
> __STDC_LIMIT_MACROS is defined. But on my system, stdint.h doesn't have
> anything like that: SIZE_MAX and related macros are unconditionally
> defined.
Indeed, the __STDC_LIMIT_MACROS definition was removed in glibc 2.18 (commit
1ef74943ce2f114c78b215af57c2ccc72ccdb0b7). That's why it only happens with old
external glibc toolchains.
Unfortunately we don't have a version symbol for glibc. But in this case, I
think the easy way out is to just add -D__STDC_LIMIT_MACROS to LIBRAW_CFLAGS
when jasper is selected. This macro isn't used anymore in recent glibc, so it
certainly doesn't hurt to define it.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 23:14 ` Arnout Vandecappelle
@ 2017-02-16 8:36 ` Thomas Petazzoni
0 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-16 8:36 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 16 Feb 2017 00:14:53 +0100, Arnout Vandecappelle wrote:
> Indeed, the __STDC_LIMIT_MACROS definition was removed in glibc 2.18 (commit
> 1ef74943ce2f114c78b215af57c2ccc72ccdb0b7). That's why it only happens with old
> external glibc toolchains.
>
> Unfortunately we don't have a version symbol for glibc. But in this case, I
> think the easy way out is to just add -D__STDC_LIMIT_MACROS to LIBRAW_CFLAGS
> when jasper is selected. This macro isn't used anymore in recent glibc, so it
> certainly doesn't hurt to define it.
Good idea, so I've done this:
https://git.buildroot.org/buildroot/commit/?id=d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (4 preceding siblings ...)
2017-02-14 22:29 ` Thomas Petazzoni
@ 2017-02-15 2:45 ` Sam Bobroff
2017-02-15 8:37 ` Thomas Petazzoni
2017-02-15 13:22 ` Gustavo Zacarias
` (2 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Sam Bobroff @ 2017-02-15 2:45 UTC (permalink / raw)
To: buildroot
On Tue, Feb 14, 2017 at 02:27:25PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> J?rg, Peter, Romain, Bernd, Gustavo, Carsten, Philippe, Yann, Fran?ois,
> Dagg, Baruch and ARC/Synopsys developers, there are some questions for
> you below.
>
> Thanks!
>
[snip]
> > powerpc64 | libsvg-0.1.4 | NOK | http://autobuild.buildroot.net/results/f2d5b2459080bf9c67906b8b240150303bb61461
>
> /usr/lib64/libexpat.so: error adding symbols: File in wrong format
> collect2: error: ld returned 1 exit status
>
> It's picking some host library, which is wrong. Carsten, you're listed
> in the DEVELOPERS file for libsvg, could you have a look?
I've had a look at this, it seems to be that pkg-config is used to
locate libxml, but when expat is used instead it just adds '-lexpat' --
which can find the host library.
Unfortunately, the change needs to be in configure.in and AUTORECONF
fails. I've experimented with creating a patch to configure that does
what I believe autoreconf should do (adds a copy of the libxml
pkg-config code adjusted for expat). Does that seem a reasonable fix?
If so, I'll post it.
Cheers,
Sam.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-15 2:45 ` Sam Bobroff
@ 2017-02-15 8:37 ` Thomas Petazzoni
0 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-15 8:37 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 15 Feb 2017 13:45:49 +1100, Sam Bobroff wrote:
> > > powerpc64 | libsvg-0.1.4 | NOK | http://autobuild.buildroot.net/results/f2d5b2459080bf9c67906b8b240150303bb61461
> >
> > /usr/lib64/libexpat.so: error adding symbols: File in wrong format
> > collect2: error: ld returned 1 exit status
> >
> > It's picking some host library, which is wrong. Carsten, you're listed
> > in the DEVELOPERS file for libsvg, could you have a look?
>
> I've had a look at this, it seems to be that pkg-config is used to
> locate libxml, but when expat is used instead it just adds '-lexpat' --
> which can find the host library.
Just passing -lexpat to the cross compiler does not lead the
cross-compiler to look in /usr/lib64. The cross-compiler normally only
looks in its sysroot for libraries.
So there must be some -L/usr/lib64 option that tells the cross-compiler
to look into this folder.
> Unfortunately, the change needs to be in configure.in and AUTORECONF
> fails. I've experimented with creating a patch to configure that does
> what I believe autoreconf should do (adds a copy of the libxml
> pkg-config code adjusted for expat). Does that seem a reasonable fix?
> If so, I'll post it.
Posting the patch would already give us some details on the conclusions
of your analysis. Not sure we will apply it as-is though.
What are the autoreconf issues? Can they be fixed easily?
BTW, do you have a minimal defconfig to reproduce the failure?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (5 preceding siblings ...)
2017-02-15 2:45 ` Sam Bobroff
@ 2017-02-15 13:22 ` Gustavo Zacarias
2017-02-16 20:34 ` Bernd Kuhls
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
8 siblings, 0 replies; 25+ messages in thread
From: Gustavo Zacarias @ 2017-02-15 13:22 UTC (permalink / raw)
To: buildroot
On 2017-02-14 10:27, Thomas Petazzoni wrote:
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/3912eaa022865ce81535fbb72a206577e32b506f
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/1e09ab626e3ecdd0467842b81200d96073af66e6
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/e2408c887dde0ad9f7120d2ab3e267da84c16484
>> arm | libepoxy-v1.3.1 | NOK |
>> http://autobuild.buildroot.net/results/7f2cdfbc125292de2427d16f9ae0b5ad971a24c2
>
> error: conflicting types for 'khronos_ssize_t'
>
> Gustavo, could you have a look ?
Hi.
Ugh, yet another problematic GL provider (odroid-mali), it's likely
related to some versions of khronos GL being, well, problematic, since i
faced the same problem with newer versions of webkitgtk for example.
I wonder if we should go the extra mile in patching this minor
nuissances since it's unlikely to get fixed upstream for these cases.
Regards.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (6 preceding siblings ...)
2017-02-15 13:22 ` Gustavo Zacarias
@ 2017-02-16 20:34 ` Bernd Kuhls
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
8 siblings, 0 replies; 25+ messages in thread
From: Bernd Kuhls @ 2017-02-16 20:34 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Am Tue, 14 Feb 2017 14:27:25 +0100 schrieb Thomas Petazzoni:
>> i586 | libcec-4.0.2 | NOK | http://
autobuild.buildroot.net/results/95bbcebc8768d1be026a83d9437a9b206b94df20
>
> /usr/lib32/libstdc++.so.6: undefined reference to
`__towlower_l at GLIBC_2.1'
> /usr/lib32/libstdc++.so.6: undefined reference to `wmemchr at GLIBC_2.0'
> /usr/lib32/libstdc++.so.6: undefined reference to `fputs at GLIBC_2.0'
>
> It's incorrectly picking some host libraries, which is wrong. Bernd,
> you did the bump of libcec, could you fix this?
I think I found the reason but I have no idea to fix it, sorry.
libcec-4.0.2/CMakeCache.txt contains these lines:
p8-platform_DIR:PATH=/home/bernd/buildroot/buildroot/output/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/p8-platform
This CMake build step
[ 97%] Linking C executable cecc-client
is done by using these commands:
/home/buildroot/buildroot/output/host/usr/bin/i586-linux-gcc --sysroot=/
home/buildroot/buildroot/output/host/usr/i586-buildroot-linux-musl/
sysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -
Os -DNDEBUG CMakeFiles/cecc-client.dir/cecc-client.c.o -o cecc-
client-4.0.2 -Wl,-rpath,/usr/lib32: -rdynamic /home/bernd/buildroot/
buildroot/output/host/usr/i586-buildroot-linux-musl/sysroot/usr/lib32/
libp8-platform.so -ldl
"-Wl,-rpath,/usr/lib32" is the reason for the linking error, imho.
Now the interesting solution:
$ cd /home/buildroot/buildroot/output/host/usr/i586-buildroot-linux-musl/
sysroot/usr/
$ LC_ALL=C ls -la
total 24
drwxr-xr-x 6 buildroot buildroot 4096 Feb 16 21:27 .
drwxr-xr-x 6 buildroot buildroot 4096 Feb 16 21:24 ..
drwxr-xr-x 2 buildroot buildroot 4096 Dec 3 16:55 bin
drwxr-xr-x 20 buildroot buildroot 4096 Feb 16 21:24 include
drwxr-xr-x 4 buildroot buildroot 4096 Feb 16 21:24 lib
lrwxrwxrwx 1 buildroot buildroot 3 Dec 3 16:55 lib32 -> lib
drwxr-xr-x 2 buildroot buildroot 4096 Dec 3 16:55 sbin
$ rm lib32
Now building libcec will work, most likely because the value of p8-
platform_DIR changed:
p8-platform_DIR:PATH=/home/bernd/buildroot/buildroot/output/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib/p8-platform
Regards, Bernd
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] [arc-buildroot] Analysis of build results for 2017-02-13
2017-02-14 13:27 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (7 preceding siblings ...)
2017-02-16 20:34 ` Bernd Kuhls
@ 2017-02-22 11:26 ` Vlad Zakharov
2017-02-22 12:48 ` Thomas Petazzoni
8 siblings, 1 reply; 25+ messages in thread
From: Vlad Zakharov @ 2017-02-22 11:26 UTC (permalink / raw)
To: buildroot
Hi all,?
sorry for the delay,
On Tue, 2017-02-14 at 14:27 +0100, Thomas Petazzoni wrote:
> >????????? arc |????????????????????? vlc-2.2.4 | NOK | http://autobuild.buildroot.net/results/b74/b7405a67745b68dcde9
> 07c1d8259851d68984694/?
>
> ARC toolchain issue. Developers from Synopsys, do you know when/if this
> is going to be fixed?
We are looking at the issue. I hope it will be solved rather wool but unfortunately I am sure fix will be ready before
BR release. So I can turn off this package now and then provide fix and turn the package on again. What do you think
about it?
Thanks.
--
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] [arc-buildroot] Analysis of build results for 2017-02-13
2017-02-22 11:26 ` [Buildroot] [arc-buildroot] " Vlad Zakharov
@ 2017-02-22 12:48 ` Thomas Petazzoni
2017-02-22 13:01 ` Vlad Zakharov
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2017-02-22 12:48 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 22 Feb 2017 11:26:00 +0000, Vlad Zakharov wrote:
> We are looking at the issue. I hope it will be solved rather wool but unfortunately I am sure fix will be ready before
> BR release.
I guess you meant "not sure" ?
> So I can turn off this package now and then provide fix and turn the
> package on again. What do you think about it?
That's OK for me. Can you send a patch doing so?
We also recently disabled the "trousers" package on ARC, also for a
toolchain reason.
Will you remember all the packages that we disabled due to an ARC
toolchain issue? Should we mark them with a special comment, so that
you can grep for it, like:
# ARC toolchain issue
depends on !BR2_arc
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [arc-buildroot] Analysis of build results for 2017-02-13
2017-02-22 12:48 ` Thomas Petazzoni
@ 2017-02-22 13:01 ` Vlad Zakharov
0 siblings, 0 replies; 25+ messages in thread
From: Vlad Zakharov @ 2017-02-22 13:01 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, 2017-02-22 at 13:48 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 22 Feb 2017 11:26:00 +0000, Vlad Zakharov wrote:
> >
> > We are looking at the issue. I hope it will be solved rather wool but unfortunately I am sure fix will be ready
> > before
> > BR release.
>
> I guess you meant "not sure" ?
You are right, it was a typo, I'm sorry.
>
> >
> > So I can turn off this package now and then provide fix and turn the
> > package on again. What do you think about it?
>
> That's OK for me. Can you send a patch doing so?
Sure, I will send it soon.
>
> We also recently disabled the "trousers" package on ARC, also for a
> toolchain reason.
>
> Will you remember all the packages that we disabled due to an ARC
> toolchain issue? Should we mark them with a special comment, so that
> you can grep for it, like:
>
> # ARC toolchain issue
> depends on !BR2_arc
We are trying to keep the list of packages disabled due to ARC toolchain failures.?
Nevertheless it sounds like a good idea - we won't miss anything.
>
> Thomas
--
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>
^ permalink raw reply [flat|nested] 25+ messages in thread