* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:07 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2016-08-19 22:19 ` Yann E. MORIN
2016-08-19 22:22 ` Waldemar Brodkorb
` (4 subsequent siblings)
5 siblings, 0 replies; 16+ messages in thread
From: Yann E. MORIN @ 2016-08-19 22:19 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2016-08-20 00:07 +0200, Thomas Petazzoni spake thusly:
> > x86_64 | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/6be08c666f783d31f3bb1a6b591186e07cb28547/
> > mips64el | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/1d5c2b717ddb9d6c333fdb4d91dc19a0c388154c/
>
> The funky C++ issue. I give one beer at the next conference to the
> person who tackles this problem that we have since at least one year
> (see
> http://autobuild.buildroot.net/results/1b6/1b6215df5e8aee157aa60530e5a90c0e9f2429c2/build-end.log,
> from August 19 2015).
I'll have a Kriek, please.
https://bugs.gnupg.org/gnupg/issue1961
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] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:07 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-08-19 22:19 ` Yann E. MORIN
@ 2016-08-19 22:22 ` Waldemar Brodkorb
2016-08-20 10:27 ` Thomas Petazzoni
2016-08-19 22:29 ` Yann E. MORIN
` (3 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Waldemar Brodkorb @ 2016-08-19 22:22 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> > bfin | binutils-2.25.1 | NOK | http://autobuild.buildroot.net/results/40c7cdd5ff8ea8020332b37628262e9636414b35/
>
> eelf32bfin.c:1790:1: error: unable to find a register to spill in class 'CCREGS'
>
> Waldemar, this is a gcc bug.
Seems simlar to the ffmpeg issue. Some kind of optimization is
broken for Blackfin in gcc 6.1.x.
> > m68k | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/1014a22cfdd3b18f349dde33f14acca4131dbd5b/
>
> Waldemar, no support of libffi for 5208. What's the plan for that?
I have a local patch for this. I will sent it out later.
> > m68k | php-7.0.9 | NOK | http://autobuild.buildroot.net/results/20b1586757450d6aad8583ad7a787a7ca11acef1/
>
> Waldemar, this is still occuring :)
I am pretty sure it will disappear, when we switched to simple FLAT
as it just seems to be a newer error message for the same problem we
are seeing with -msep-data.
best regards
Waldemar
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:22 ` Waldemar Brodkorb
@ 2016-08-20 10:27 ` Thomas Petazzoni
0 siblings, 0 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2016-08-20 10:27 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 20 Aug 2016 00:22:38 +0200, Waldemar Brodkorb wrote:
> > eelf32bfin.c:1790:1: error: unable to find a register to spill in class 'CCREGS'
> >
> > Waldemar, this is a gcc bug.
>
> Seems simlar to the ffmpeg issue. Some kind of optimization is
> broken for Blackfin in gcc 6.1.x.
OK. Can you cook a patch for this one as well?
Ideally, we should fix the gcc problem, but I clearly don't have enough
knowledge about gcc internals to fix this one I believe. Though it
would be a good opportunity to learn about such internals.
> > > m68k | libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/1014a22cfdd3b18f349dde33f14acca4131dbd5b/
> >
> > Waldemar, no support of libffi for 5208. What's the plan for that?
>
> I have a local patch for this. I will sent it out later.
Applied, thanks.
> > > m68k | php-7.0.9 | NOK | http://autobuild.buildroot.net/results/20b1586757450d6aad8583ad7a787a7ca11acef1/
> >
> > Waldemar, this is still occuring :)
>
> I am pretty sure it will disappear, when we switched to simple FLAT
> as it just seems to be a newer error message for the same problem we
> are seeing with -msep-data.
OK. I guess you'll send a patch series about this soonish?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:07 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-08-19 22:19 ` Yann E. MORIN
2016-08-19 22:22 ` Waldemar Brodkorb
@ 2016-08-19 22:29 ` Yann E. MORIN
2016-08-24 16:51 ` Thomas Petazzoni
2016-08-20 9:17 ` [Buildroot] Analysis of build results for 2016-08-18 Rahul Bedarkar
` (2 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Yann E. MORIN @ 2016-08-19 22:29 UTC (permalink / raw)
To: buildroot
Thomas, All,
Now I won the beer, the serious reply...
On 2016-08-20 00:07 +0200, Thomas Petazzoni spake thusly:
> > arm | kmsxx-bd5f6471e619a6ba2987b... | NOK | http://autobuild.buildroot.net/results/6e91cfb1a0a55d1e816de66353bf6a4053af05a5/
>
> [ 41%] Linking CXX static library ../lib/libkms++.a
> Error running link command: No such file or directory
>
> Yann ?
I was not able to reproduce after ~10 successive builds, all repeated on
three different systems: my laptop (Ubuntu 16.04), my server (Ubuntu
14.04) or my autobuilder instance (Ubuntu 12.04 IIRC).
There is another type of issues for kmsxx:
http://autobuild.buildroot.org/results/5e9/5e9963c1f11af40a6349da524fc128116a1d9e6e/build-end.log
[ 81%] Linking CXX executable ../bin/fbtestpat
/tmp/ccvhwy4u.ltrans0.ltrans.o: In function `main':
<artificial>:(.text.startup+0xa4): undefined reference to `kms::ExtCPUFramebuffer::ExtCPUFramebuffer(unsigned int, unsigned int, kms::PixelFormat, unsigned char*, unsigned int)'
<artificial>:(.text.startup+0xd4): undefined reference to `kms::draw_test_pattern(kms::IMappedFramebuffer&)'
<artificial>:(.text.startup+0x10c): undefined reference to `kms::RGB::RGB(unsigned char, unsigned char, unsigned char)'
<artificial>:(.text.startup+0x128): undefined reference to `kms::draw_text(kms::IMappedFramebuffer&, unsigned int, unsigned int, std::string const&, kms::RGB)'
<artificial>:(.text.startup+0x188): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
<artificial>:(.text.startup+0x2a8): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
collect2: error: ld returned 1 exit status
make[3]: *** [bin/fbtestpat] Error 1
And I was not able to reproduce it either... :-/
> > aarch64 | lldpd-0.9.4 | NOK | http://autobuild.buildroot.net/results/279591190dd7676ff4bcbb6017a109af7b7d67e9/
> > x86_64 | lldpd-0.9.4 | NOK | http://autobuild.buildroot.net/results/6b92fa15853bfeca8dd1dff15fcc57bef81194cc/
>
> The libbsd issue. I'm not sure how to solve without fixing pkg-config.
> What do we do for the release? Take the not-so-nice patch proposed by
> Yann to work around the problem?
>
> Secondary question: other packages are using libbsd, why aren't we
> seeing other occurrences of this problem?
Because none is using libbsd-overlay.pc, just libbsd.pc.
The underlying issue, that pkconf does not munge -isystem, is being
investigated by the pkconf guys:
https://github.com/pkgconf/pkgconf/issues/94
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] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:29 ` Yann E. MORIN
@ 2016-08-24 16:51 ` Thomas Petazzoni
2016-08-24 20:40 ` [Buildroot] Remaining kmsxx build issue Thomas Petazzoni
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-08-24 16:51 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 20 Aug 2016 00:29:25 +0200, Yann E. MORIN wrote:
> There is another type of issues for kmsxx:
>
> http://autobuild.buildroot.org/results/5e9/5e9963c1f11af40a6349da524fc128116a1d9e6e/build-end.log
>
> [ 81%] Linking CXX executable ../bin/fbtestpat
> /tmp/ccvhwy4u.ltrans0.ltrans.o: In function `main':
> <artificial>:(.text.startup+0xa4): undefined reference to `kms::ExtCPUFramebuffer::ExtCPUFramebuffer(unsigned int, unsigned int, kms::PixelFormat, unsigned char*, unsigned int)'
> <artificial>:(.text.startup+0xd4): undefined reference to `kms::draw_test_pattern(kms::IMappedFramebuffer&)'
> <artificial>:(.text.startup+0x10c): undefined reference to `kms::RGB::RGB(unsigned char, unsigned char, unsigned char)'
> <artificial>:(.text.startup+0x128): undefined reference to `kms::draw_text(kms::IMappedFramebuffer&, unsigned int, unsigned int, std::string const&, kms::RGB)'
> <artificial>:(.text.startup+0x188): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
> <artificial>:(.text.startup+0x2a8): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
> collect2: error: ld returned 1 exit status
> make[3]: *** [bin/fbtestpat] Error 1
>
> And I was not able to reproduce it either... :-/
This issue happened only once:
http://autobuild.buildroot.net/?reason=kmsxx-bd5f6471e619a6ba2987bc7f66ef78a531f94d6c
I've restarted the same build on the same machine, I'll see if it
happens again.
> > Secondary question: other packages are using libbsd, why aren't we
> > seeing other occurrences of this problem?
>
> Because none is using libbsd-overlay.pc, just libbsd.pc.
OK.
> The underlying issue, that pkconf does not munge -isystem, is being
> investigated by the pkconf guys:
> https://github.com/pkgconf/pkgconf/issues/94
OK. I'll apply your lldpd workaround then.
Thanks for the feedback!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Remaining kmsxx build issue
2016-08-24 16:51 ` Thomas Petazzoni
@ 2016-08-24 20:40 ` Thomas Petazzoni
2016-08-26 19:30 ` Arnout Vandecappelle
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-08-24 20:40 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 24 Aug 2016 18:51:28 +0200, Thomas Petazzoni wrote:
> > There is another type of issues for kmsxx:
> >
> > http://autobuild.buildroot.org/results/5e9/5e9963c1f11af40a6349da524fc128116a1d9e6e/build-end.log
> >
> > [ 81%] Linking CXX executable ../bin/fbtestpat
> > /tmp/ccvhwy4u.ltrans0.ltrans.o: In function `main':
> > <artificial>:(.text.startup+0xa4): undefined reference to `kms::ExtCPUFramebuffer::ExtCPUFramebuffer(unsigned int, unsigned int, kms::PixelFormat, unsigned char*, unsigned int)'
> > <artificial>:(.text.startup+0xd4): undefined reference to `kms::draw_test_pattern(kms::IMappedFramebuffer&)'
> > <artificial>:(.text.startup+0x10c): undefined reference to `kms::RGB::RGB(unsigned char, unsigned char, unsigned char)'
> > <artificial>:(.text.startup+0x128): undefined reference to `kms::draw_text(kms::IMappedFramebuffer&, unsigned int, unsigned int, std::string const&, kms::RGB)'
> > <artificial>:(.text.startup+0x188): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
> > <artificial>:(.text.startup+0x2a8): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
> > collect2: error: ld returned 1 exit status
> > make[3]: *** [bin/fbtestpat] Error 1
> >
> > And I was not able to reproduce it either... :-/
>
> This issue happened only once:
>
> http://autobuild.buildroot.net/?reason=kmsxx-bd5f6471e619a6ba2987bc7f66ef78a531f94d6c
>
> I've restarted the same build on the same machine, I'll see if it
> happens again.
I've been able to reproduce it on gcc20, and a reduced test case is:
BR2_arm=y
BR2_STATIC_LIBS=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-static-2016.08-rc1-4-g07e8d1c.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_14=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_KMSXX=y
The exact same defconfig builds fine on my laptop.
On gcc20, I'm able to fix the build by disabling LTO support in the
kmsxx CMakeLists.txt file. I.e, I remove:
if (NOT ${U_CMAKE_BUILD_TYPE} MATCHES DEBUG)
CHECK_CXX_COMPILER_FLAG("-flto" HAS_LTO_FLAG)
if (HAS_LTO_FLAG)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
set(CMAKE_AR gcc-ar)
set(CMAKE_RANLIB gcc-ranlib)
endif()
endif()
And then the build works.
While I could imagine some LTO-related bug, I cannot understand why
with the exact same toolchain/cross-compiler it builds on my laptop but
not on gcc20.
Completely weird.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Remaining kmsxx build issue
2016-08-24 20:40 ` [Buildroot] Remaining kmsxx build issue Thomas Petazzoni
@ 2016-08-26 19:30 ` Arnout Vandecappelle
2016-08-26 19:42 ` Thomas Petazzoni
0 siblings, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle @ 2016-08-26 19:30 UTC (permalink / raw)
To: buildroot
On 24-08-16 22:40, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 24 Aug 2016 18:51:28 +0200, Thomas Petazzoni wrote:
>
>>> There is another type of issues for kmsxx:
>>>
>>> http://autobuild.buildroot.org/results/5e9/5e9963c1f11af40a6349da524fc128116a1d9e6e/build-end.log
>>>
>>> [ 81%] Linking CXX executable ../bin/fbtestpat
>>> /tmp/ccvhwy4u.ltrans0.ltrans.o: In function `main':
>>> <artificial>:(.text.startup+0xa4): undefined reference to `kms::ExtCPUFramebuffer::ExtCPUFramebuffer(unsigned int, unsigned int, kms::PixelFormat, unsigned char*, unsigned int)'
>>> <artificial>:(.text.startup+0xd4): undefined reference to `kms::draw_test_pattern(kms::IMappedFramebuffer&)'
>>> <artificial>:(.text.startup+0x10c): undefined reference to `kms::RGB::RGB(unsigned char, unsigned char, unsigned char)'
>>> <artificial>:(.text.startup+0x128): undefined reference to `kms::draw_text(kms::IMappedFramebuffer&, unsigned int, unsigned int, std::string const&, kms::RGB)'
>>> <artificial>:(.text.startup+0x188): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
>>> <artificial>:(.text.startup+0x2a8): undefined reference to `kms::ExtCPUFramebuffer::~ExtCPUFramebuffer()'
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [bin/fbtestpat] Error 1
>>>
>>> And I was not able to reproduce it either... :-/
>>
>> This issue happened only once:
>>
>> http://autobuild.buildroot.net/?reason=kmsxx-bd5f6471e619a6ba2987bc7f66ef78a531f94d6c
>>
>> I've restarted the same build on the same machine, I'll see if it
>> happens again.
>
> I've been able to reproduce it on gcc20, and a reduced test case is:
>
> BR2_arm=y
> BR2_STATIC_LIBS=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-static-2016.08-rc1-4-g07e8d1c.tar.bz2"
> BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y
> BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_14=y
> BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
> # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
> BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> BR2_PACKAGE_KMSXX=y
>
> The exact same defconfig builds fine on my laptop.
>
> On gcc20, I'm able to fix the build by disabling LTO support in the
> kmsxx CMakeLists.txt file. I.e, I remove:
>
> if (NOT ${U_CMAKE_BUILD_TYPE} MATCHES DEBUG)
> CHECK_CXX_COMPILER_FLAG("-flto" HAS_LTO_FLAG)
>
> if (HAS_LTO_FLAG)
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
> set(CMAKE_AR gcc-ar)
I also can't reproduce on my laptop, unless when I remove /usr/bin/gcc-ar :-)
This piece of code is obviously broken. Unfortunately, I'm not sure how to fix
it. Replace gcc-ar with ${CMAKE_C_COMPILER}-ar ? But that doesn't work if
BR2_CCACHE=y... Symlink gcc-ar -> cross-gcc-ar in host/usr/bin? But that could
create a discrepancy between the host gcc's LTO tools and the cross-tools.
Oh, hang on, some genius moved the ccache support to the toolchain wrapper, so
${CMAKE_C_COMPILER}-ar might actually work... Let me try that...
Regards,
Arnout
> set(CMAKE_RANLIB gcc-ranlib)
> endif()
> endif()
>
> And then the build works.
>
> While I could imagine some LTO-related bug, I cannot understand why
> with the exact same toolchain/cross-compiler it builds on my laptop but
> not on gcc20.
>
> Completely weird.
>
> Thomas
>
--
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] 16+ messages in thread
* [Buildroot] Remaining kmsxx build issue
2016-08-26 19:30 ` Arnout Vandecappelle
@ 2016-08-26 19:42 ` Thomas Petazzoni
0 siblings, 0 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2016-08-26 19:42 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 26 Aug 2016 21:30:09 +0200, Arnout Vandecappelle wrote:
> I also can't reproduce on my laptop, unless when I remove /usr/bin/gcc-ar :-)
>
> This piece of code is obviously broken. Unfortunately, I'm not sure how to fix
> it. Replace gcc-ar with ${CMAKE_C_COMPILER}-ar ? But that doesn't work if
> BR2_CCACHE=y... Symlink gcc-ar -> cross-gcc-ar in host/usr/bin? But that could
> create a discrepancy between the host gcc's LTO tools and the cross-tools.
>
> Oh, hang on, some genius moved the ccache support to the toolchain wrapper, so
> ${CMAKE_C_COMPILER}-ar might actually work... Let me try that...
Shouldn't instead this CMakeLists.txt allow to override the gcc-ar and
gcc-ranlib path using variables, like CMake normally does for the C and
C++ compilers with CMAKE_C_COMPILER and CMAKE_CXX_COMPILER ?
Samuel ?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:07 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2016-08-19 22:29 ` Yann E. MORIN
@ 2016-08-20 9:17 ` Rahul Bedarkar
2016-08-20 9:22 ` Thomas Petazzoni
2016-08-20 13:52 ` Gustavo Zacarias
2016-08-21 6:42 ` [Buildroot] Analysis of build results for 2016-08-18 Baruch Siach
5 siblings, 1 reply; 16+ messages in thread
From: Rahul Bedarkar @ 2016-08-20 9:17 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
On Saturday 20 August 2016 03:37 AM, Thomas Petazzoni wrote:
>
>> arc | jack2-v1.9.10 | NOK | http://autobuild.buildroot.net/results/8a8d533a0f785591fee10f1c09c9294f892ef7f7/
>
> gcc 6.x issue:
>
> ../tests/iodelay.cpp:170:49: error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
> ../tests/iodelay.cpp:171:50: error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
>
> I guess
> https://github.com/jackaudio/jack2/commit/ff1ed2c4524095055140370c1008a2d9cccc5645
> should fix it.
>
Thanks. I have sent patch to fix this issue.
https://patchwork.ozlabs.org/patch/661117/
>
>> x86_64 | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/c9b13ae8d4af9ae6a65921de142c0e8da30664e0/
>
> tsp_tcsi_param.c:14:28: fatal error: bits/local_lim.h: No such file or directory
> #include <bits/local_lim.h>
>
> No?, since you added this package, could you have a look?
>
I have fixed similar issue for mtd package and can take a look.
https://git.buildroot.net/buildroot/commit/?id=850e74c3639733986ff40b96fbca7d355aee738c
Thanks,
Rahul
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-20 9:17 ` [Buildroot] Analysis of build results for 2016-08-18 Rahul Bedarkar
@ 2016-08-20 9:22 ` Thomas Petazzoni
2016-08-20 10:11 ` Rahul Bedarkar
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-08-20 9:22 UTC (permalink / raw)
To: buildroot
Hello,
On Sat, 20 Aug 2016 14:47:03 +0530, Rahul Bedarkar wrote:
> > I guess
> > https://github.com/jackaudio/jack2/commit/ff1ed2c4524095055140370c1008a2d9cccc5645
> > should fix it.
>
> Thanks. I have sent patch to fix this issue.
> https://patchwork.ozlabs.org/patch/661117/
Great, thanks!
> > tsp_tcsi_param.c:14:28: fatal error: bits/local_lim.h: No such file or directory
> > #include <bits/local_lim.h>
> >
> > No?, since you added this package, could you have a look?
> >
>
> I have fixed similar issue for mtd package and can take a look.
> https://git.buildroot.net/buildroot/commit/?id=850e74c3639733986ff40b96fbca7d355aee738c
That would be nice, thanks!
Also, did you see the MIPS related issues on the qt5webkit package I
pointed in my latest analysis of build issues? Since you're working for
imgtec, I thought you might have some MIPS knowledge :)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-20 9:22 ` Thomas Petazzoni
@ 2016-08-20 10:11 ` Rahul Bedarkar
0 siblings, 0 replies; 16+ messages in thread
From: Rahul Bedarkar @ 2016-08-20 10:11 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Saturday 20 August 2016 02:52 PM, Thomas Petazzoni wrote:
>
> Also, did you see the MIPS related issues on the qt5webkit package I
> pointed in my latest analysis of build issues? Since you're working for
> imgtec, I thought you might have some MIPS knowledge :)
>
I'm not sure if I could fix it. But I will definitely try. :)
Regards,
Rahul
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:07 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (3 preceding siblings ...)
2016-08-20 9:17 ` [Buildroot] Analysis of build results for 2016-08-18 Rahul Bedarkar
@ 2016-08-20 13:52 ` Gustavo Zacarias
2016-08-20 13:55 ` [Buildroot] odroid-mali issue Thomas Petazzoni
2016-08-21 6:42 ` [Buildroot] Analysis of build results for 2016-08-18 Baruch Siach
5 siblings, 1 reply; 16+ messages in thread
From: Gustavo Zacarias @ 2016-08-20 13:52 UTC (permalink / raw)
To: buildroot
On 19/08/16 19:07, Thomas Petazzoni wrote:
>> aarch64 | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/3efe300199759fb84ad8122abc36bbcdfa10e0cd/
>
> error: conflicting types for 'khronos_uint64_t'
>
> Gustavo?
Hi.
This only happens when odroid-mali is the GL provider, i suspect they
messed up something in there.
From a quick look they define the khronos_uint64_t typedef in several
places with no checks whatsoever, and that probably shouldn't be.
I suspect more of odroid-mali flakyness than libepoxy since it works
with other providers just fine, i'll try to dig more info about it.
Regards.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] odroid-mali issue
2016-08-20 13:52 ` Gustavo Zacarias
@ 2016-08-20 13:55 ` Thomas Petazzoni
0 siblings, 0 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2016-08-20 13:55 UTC (permalink / raw)
To: buildroot
Hello Dagg,
On Sat, 20 Aug 2016 10:52:22 -0300, Gustavo Zacarias wrote:
> >> aarch64 | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/3efe300199759fb84ad8122abc36bbcdfa10e0cd/
> >
> > error: conflicting types for 'khronos_uint64_t'
> >
> > Gustavo?
>
> Hi.
> This only happens when odroid-mali is the GL provider, i suspect they
> messed up something in there.
> From a quick look they define the khronos_uint64_t typedef in several
> places with no checks whatsoever, and that probably shouldn't be.
> I suspect more of odroid-mali flakyness than libepoxy since it works
> with other providers just fine, i'll try to dig more info about it.
There's an issue with the odroid-mali OpenGL provider, when used by
libepoxy. Could you have a look at the issue, that Gustavo investigated
here?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-18
2016-08-19 22:07 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (4 preceding siblings ...)
2016-08-20 13:52 ` Gustavo Zacarias
@ 2016-08-21 6:42 ` Baruch Siach
5 siblings, 0 replies; 16+ messages in thread
From: Baruch Siach @ 2016-08-21 6:42 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Sat, Aug 20, 2016 at 12:07:09AM +0200, Thomas Petazzoni wrote:
> > mips64el | quagga-1.0.20160315 | NOK | http://autobuild.buildroot.net/results/01317aeaff7d127a05e0488a51e81f2d43750687/
>
> /home/buildroot/build/instance-1/output/host/usr/mips64el-buildroot-linux-uclibc/sysroot/usr/lib/libz.a(zutil.o): In function `zcalloc':
> zutil.c:(.text+0x48): multiple definition of `zcalloc'
> /home/buildroot/build/instance-1/output/build/quagga-1.0.20160315/lib/.libs/libzebra.a(memory.o):memory.c:(.text+0x1a0): first defined here
> collect2: error: ld returned 1 exit status
>
> Should not be too difficult to fix. Gustavo? Or Baruch maybe?
Should be fixed by http://patchwork.ozlabs.org/patch/661213/.
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] 16+ messages in thread