* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18
@ 2017-05-19 6:31 Thomas Petazzoni
2017-05-19 6:34 ` [Buildroot] Xorg and buildroot ? Riko Ho
2017-05-19 19:44 ` [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
0 siblings, 2 replies; 8+ messages in thread
From: Thomas Petazzoni @ 2017-05-19 6:31 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2017-05-18
================================
successes : 276
failures : 10
timeouts : 1
TOTAL : 287
Classification of failures by reason
====================================
libepoxy-1.4.1 | 2
mplayer-1.3.0 | 2
cegui06-0.6.2b | 1
modem-manager-1.6.4 | 1
php-7.1.5 | 1
qt5base-5.8.0 | 1
quagga-1.1.1 | 1
taskd-1.1.0 | 1
vpnc-b1243d29e0c00312ead038... | 1
Detail of failures
===================
arm | cegui06-0.6.2b | TIM | http://autobuild.buildroot.net/results/614a7ffd798552d9fa14e2550fd93de82279032d |
arm | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/6a495d25f3d87ae00254258fa862884ffada09b4 |
xtensa | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/44c7fa9f2ecda70ed4fa58019d31a39739914662 |
arm | modem-manager-1.6.4 | NOK | http://autobuild.buildroot.net/results/8beab6e29fad77eea8a0f3e3129dcde2b7cfdcc8 |
arm | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/5dfdd18bc9aa0713bf8eb8e5f374932686b13d9b |
x86_64 | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/29f572c35815b8e474f137039a7db9f8499fb0e3 |
i686 | php-7.1.5 | NOK | http://autobuild.buildroot.net/results/6e1cb08d385b1a406c0c0d4960bfb279d3137020 | ORPH
sparc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/995656a6f9fff594af6b10297253788683a0098f |
arc | quagga-1.1.1 | NOK | http://autobuild.buildroot.net/results/ffc84eb08e32dabdccc579d67c8d1f8ae71ab1e4 | ORPH
microblazeel | taskd-1.1.0 | NOK | http://autobuild.buildroot.net/results/b8c18a2cc5e7170695c273e8017a4771096167b6 |
sparc | vpnc-b1243d29e0c00312ead038... | NOK | http://autobuild.buildroot.net/results/54c2daad582fab6558815608ea388e8ec82ea384 | ORPH
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] Xorg and buildroot ?
2017-05-19 6:31 [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
@ 2017-05-19 6:34 ` Riko Ho
2017-05-19 7:08 ` Thomas Petazzoni
2017-05-19 19:44 ` [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
1 sibling, 1 reply; 8+ messages in thread
From: Riko Ho @ 2017-05-19 6:34 UTC (permalink / raw)
To: buildroot
I tried to run xorg in qemu and got, it's X86_64 architecture and I can
not see complete xorg.conf.
===
# startx
expr: warning: '^/dev/tty[0-9]\+$': using '^' as the first character
of a basic regular expression is not portable; it is ignored
xauth: file /root/.serverauth.1032 does not exist
xauth: file /root/.Xauthority does not exist
X.Org X Server 1.14.7
Release Date: 2014-06-05
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-75-generic x86_64
Current Operating System: Linux RikoRoot 4.11.0 #1 SMP Fri May 19
11:38:11 AWST 2017 x86_64
Kernel command line: console=ttyS0
Build Date: 19 May 2017 10:53:50AM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 06:32:26 2017
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension DAMAGE
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension XFree86-VidModeExtension
Initializing built-in extension XFree86-DGA
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for
additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
====
Any ideas ?
--
*
/*******/
Sent by Ubuntu LTS 16.04,
??,
Regards,
Riko Ho
/*******/
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170519/0d1aaa76/attachment.html>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] Xorg and buildroot ?
2017-05-19 6:34 ` [Buildroot] Xorg and buildroot ? Riko Ho
@ 2017-05-19 7:08 ` Thomas Petazzoni
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Petazzoni @ 2017-05-19 7:08 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 19 May 2017 14:34:43 +0800, Riko Ho wrote:
> Fatal server error:
> (EE) no screens found(EE)
> (EE)
> Please consult the The X.Org Foundation support
> at http://wiki.x.org
> for help.
> (EE) Please also check the log file at "/var/log/Xorg.0.log" for
> additional information.
> (EE)
> (EE) Server terminated with error (1). Closing log file.
>
> ====
>
> Any ideas ?
What graphics HW do you have, what is your Buildroot .config, and which
version of Buildroot are you using ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18
2017-05-19 6:31 [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
2017-05-19 6:34 ` [Buildroot] Xorg and buildroot ? Riko Ho
@ 2017-05-19 19:44 ` Thomas Petazzoni
2017-05-19 20:39 ` Yann E. MORIN
` (2 more replies)
1 sibling, 3 replies; 8+ messages in thread
From: Thomas Petazzoni @ 2017-05-19 19:44 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 19 May 2017 08:31:57 +0200 (CEST), Thomas Petazzoni wrote:
> arm | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/6a495d25f3d87ae00254258fa862884ffada09b4 |
> xtensa | libepoxy-1.4.1 | NOK | http://autobuild.buildroot.net/results/44c7fa9f2ecda70ed4fa58019d31a39739914662 |
I've sent a patch for these:
https://patchwork.ozlabs.org/patch/764820/
> arm | modem-manager-1.6.4 | NOK | http://autobuild.buildroot.net/results/8beab6e29fad77eea8a0f3e3129dcde2b7cfdcc8 |
Already fixed by:
https://git.buildroot.org/buildroot/commit/?id=2677210f545c3f3e8c52c973e08c3a460c521e5b
> arm | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/5dfdd18bc9aa0713bf8eb8e5f374932686b13d9b |
> x86_64 | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/29f572c35815b8e474f137039a7db9f8499fb0e3 |
libpostproc/postprocess.c:94:53: error: expected ',' or ';' before 'FFMPEG_VERSION'
const char postproc_ffversion[] = "FFmpeg version " FFMPEG_VERSION;
This error is weird, it happens on different architectures. I'll try to reproduce.
> i686 | php-7.1.5 | NOK | http://autobuild.buildroot.net/results/6e1cb08d385b1a406c0c0d4960bfb279d3137020 | ORPH
/home/buildroot/autobuild/run/instance-1/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/libicui18n.a(umsg.o): In function `icu_58::MessageFormatAdapter::getArgTypeList(icu_58::MessageFormat const&, int&)':
umsg.cpp:(.text._ZN6icu_5820MessageFormatAdapter14getArgTypeListERKNS_13MessageFormatERi+0x0): multiple definition of `icu_58::MessageFormatAdapter::getArgTypeList(icu_58::MessageFormat const&, int&)'
ext/intl/msgformat/msgformat_helpers.o:msgformat_helpers.cpp:(.text+0x24): first defined here
collect2: error: ld returned 1 exit status
Static linking configuration.
> sparc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/995656a6f9fff594af6b10297253788683a0098f |
This would be fixed by:
https://patchwork.ozlabs.org/patch/763762/
https://patchwork.ozlabs.org/patch/763763/
I was hoping to get some review/feedback from Peter Seiderer on this.
Peter, could you have a look?
> arc | quagga-1.1.1 | NOK | http://autobuild.buildroot.net/results/ffc84eb08e32dabdccc579d67c8d1f8ae71ab1e4 | ORPH
Compiler failure on ARC:
ospf_ri.c:839:1: internal compiler error: in extract_insn, at recog.c:2287
Alexey, is this one already known?
> microblazeel | taskd-1.1.0 | NOK | http://autobuild.buildroot.net/results/b8c18a2cc5e7170695c273e8017a4771096167b6 |
Issue when linking against gnutls, itself linked against libunistring.
Romain and I have already identified an issue in gnutls .pc file while
investigating a ffmpeg build failure. It might be the same issue here.
> sparc | vpnc-b1243d29e0c00312ead038... | NOK | http://autobuild.buildroot.net/results/54c2daad582fab6558815608ea388e8ec82ea384 | ORPH
Classical libintl missing when statically linking.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18
2017-05-19 19:44 ` [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
@ 2017-05-19 20:39 ` Yann E. MORIN
2017-05-20 7:03 ` Peter Seiderer
2017-05-20 10:10 ` Romain Naour
2017-05-22 19:22 ` Alexey Brodkin
2 siblings, 1 reply; 8+ messages in thread
From: Yann E. MORIN @ 2017-05-19 20:39 UTC (permalink / raw)
To: buildroot
Thomas, Peter (S), All,
On 2017-05-19 21:44 +0200, Thomas Petazzoni spake thusly:
> > sparc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/995656a6f9fff594af6b10297253788683a0098f |
> This would be fixed by:
> https://patchwork.ozlabs.org/patch/763762/
> https://patchwork.ozlabs.org/patch/763763/
> I was hoping to get some review/feedback from Peter Seiderer on this.
> Peter, could you have a look?
I am afraid that I may have to withdraw my patches.
I was looking again at this build failure, and we can see that, prior to
checking for atomicfptr, it already tests for libatomic:
Checking for 64 bit atomics...
[...]
> atomic64.cpp:(.text+0x28): undefined reference to `__atomic_exchange_8'
> atomic64.cpp:(.text+0x48): undefined reference to `__atomic_compare_exchange_8'
[...]
test config.corelib.tests.atomic64 FAILED
Checking for 64 bit atomics in libatomic...
[...]
[...]/sparc-linux-g++ [...] -Wl,-O1 -o atomic64 atomic64.o -lrt -lpthread -ldl -latomic
=> source accepted.
test config.corelib.libraries.libatomic succeeded
But then it forgets to link with it when it looks for atomicfptr:
[...]/sparc-linux-g++ [...] -Wl,-O1 -o atomicfptr atomicfptr.o -lrt -lpthread -ldl
> atomicfptr.o: In function `test(std::atomic<void (*)(int)> volatile&)':
> atomicfptr.cpp:(.text+0x4c): undefined reference to `__atomic_compare_exchange_4'
So, in my opinion, the real and correct fix would be to have the
atomicfptr test actually use the result of the previous libatomic test.
I've had a (rather quick) look, and I have no idea on how to do this...
Peter (Seiderer), we'd need some help on this...
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] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18
2017-05-19 20:39 ` Yann E. MORIN
@ 2017-05-20 7:03 ` Peter Seiderer
0 siblings, 0 replies; 8+ messages in thread
From: Peter Seiderer @ 2017-05-20 7:03 UTC (permalink / raw)
To: buildroot
On Fri, 19 May 2017 22:39:58 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
Hello Yann,
> Thomas, Peter (S), All,
>
> On 2017-05-19 21:44 +0200, Thomas Petazzoni spake thusly:
> > > sparc | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/995656a6f9fff594af6b10297253788683a0098f |
> > This would be fixed by:
> > https://patchwork.ozlabs.org/patch/763762/
> > https://patchwork.ozlabs.org/patch/763763/
> > I was hoping to get some review/feedback from Peter Seiderer on this.
> > Peter, could you have a look?
>
> I am afraid that I may have to withdraw my patches.
>
> I was looking again at this build failure, and we can see that, prior to
> checking for atomicfptr, it already tests for libatomic:
>
> Checking for 64 bit atomics...
> [...]
> > atomic64.cpp:(.text+0x28): undefined reference to `__atomic_exchange_8'
> > atomic64.cpp:(.text+0x48): undefined reference to `__atomic_compare_exchange_8'
> [...]
> test config.corelib.tests.atomic64 FAILED
> Checking for 64 bit atomics in libatomic...
> [...]
> [...]/sparc-linux-g++ [...] -Wl,-O1 -o atomic64 atomic64.o -lrt -lpthread -ldl -latomic
> => source accepted.
> test config.corelib.libraries.libatomic succeeded
>
> But then it forgets to link with it when it looks for atomicfptr:
>
> [...]/sparc-linux-g++ [...] -Wl,-O1 -o atomicfptr atomicfptr.o -lrt -lpthread -ldl
> > atomicfptr.o: In function `test(std::atomic<void (*)(int)> volatile&)':
> > atomicfptr.cpp:(.text+0x4c): undefined reference to `__atomic_compare_exchange_4'
>
> So, in my opinion, the real and correct fix would be to have the
> atomicfptr test actually use the result of the previous libatomic test.
>
Yes, this would be the 'perfect' solution, but...
> I've had a (rather quick) look, and I have no idea on how to do this...
> Peter (Seiderer), we'd need some help on this...
Did play around a little bit hacking src/corelib/configure.json and
config.tests/common/atomicfptr/atomicfptr.pro but no success so far...
So I think your patches look like the best workaround so far...
Regards,
Peter
>
> Regards,
> Yann E. MORIN.
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18
2017-05-19 19:44 ` [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
2017-05-19 20:39 ` Yann E. MORIN
@ 2017-05-20 10:10 ` Romain Naour
2017-05-22 19:22 ` Alexey Brodkin
2 siblings, 0 replies; 8+ messages in thread
From: Romain Naour @ 2017-05-20 10:10 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Le 19/05/2017 ? 21:44, Thomas Petazzoni a ?crit :
> Hello,
>
[...]
>
>> microblazeel | taskd-1.1.0 | NOK | http://autobuild.buildroot.net/results/b8c18a2cc5e7170695c273e8017a4771096167b6 |
>
> Issue when linking against gnutls, itself linked against libunistring.
> Romain and I have already identified an issue in gnutls .pc file while
> investigating a ffmpeg build failure. It might be the same issue here.
>
Indeed, see ffmpeg build issue [1].
gnutls.pc contain the full path to libunistring library which trigger an issue
when compiling with "gcc -c" (Compile and assemble, but do not link). When
compiling with "gcc -c", a full path is not accepted, while -lfoo is.
gnutls.pc for static libraries build:
Libs.private: -lintl -lgmp [...]sysroot/usr/lib/libunistring.a
gnutls.pc for shared libraries build:
Libs.private: -lgmp [...]/sysroot/usr/lib/libunistring.so
That's because gnutls use AC_LIB_HAVE_LINKFLAGS [2] witch return the full
library path in LIBUNISTRING. If LTLIBUNISTRING is used in gnutls.pc.in then the
issue is "fixed":
Libs.private: -lintl -lgmp -lunistring
But it's probably a hack...
We don't have a problem with zlib since gnutls build system use zlib.pc thanks
to pkg-config (otherwise we have the same issue with zlib...).
For LIBINTL the AM_GNU_GETTEXT macro is used and return LIBINTL='-lintl'.
GMP_LIBS is set from LIBGNUTLS_HOOKS (m4/hooks.m4) which use AC_CHECK_LIB and
return -lgmp.
The remaining libraries LIBSOCKET, LIBNSL, LIBPTHREAD, LIB_SELECT, TSS_LIBS and
LIBIDN2_LIBS are empty.
We can't use PKG_CHECK_MODULES for libunistring since it doesn't provide a .pc
file. The remaining solution is AC_CHECK_LIB() instead of AC_LIB_HAVE_LINKFLAGS,
it could work since libunistring doesn't link with other libraries (-lunistring
is enough). But we have to do an "invasive" change in the build system.
So I would suggest s/LIBUNISTRING/LTLIBUNISTRING/ in gnutls.pc.
Also having a full path is a .pc file is a problem for relocatable SDK [3] if
you move your HOST_DIR (which contain the STAGING_DIR).
Best regards,
Romain
[1]
http://autobuild.buildroot.net/results/6cf/6cf90177a444882ad37017bccf41dea6bf752d31/ffmpeg-3.3.1/config.log
[2]
https://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html
[3] http://lists.busybox.net/pipermail/buildroot/2017-March/187695.html
>
> Best regards,
>
> Thomas
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18
2017-05-19 19:44 ` [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
2017-05-19 20:39 ` Yann E. MORIN
2017-05-20 10:10 ` Romain Naour
@ 2017-05-22 19:22 ` Alexey Brodkin
2 siblings, 0 replies; 8+ messages in thread
From: Alexey Brodkin @ 2017-05-22 19:22 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Fri, 2017-05-19 at 21:44 +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 19 May 2017 08:31:57 +0200 (CEST), Thomas Petazzoni wrote:
>?
> > ?????????arc |???????????????????quagga-1.1.1 | NOK | https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_ffc84eb0
> > 8e32dabdccc579d67c8d1f8ae71ab1e4&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=0LYQlMzI9D5n6XsyeqEGqg4ii88QIXh
> > 418hRH-Uw8cA&s=mu0MUYnbYvnsfZGE0JraJzF0s4kBlmHjASZovSIox8M&e=??| ORPH
>
> Compiler failure on ARC:
>
> ? ospf_ri.c:839:1: internal compiler error: in extract_insn, at recog.c:2287
>
> Alexey, is this one already known?
Nope, just reported it to our compiler guy.
Hopefully it gets fixed in a day or two, stay tuned.
-Alexey
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-05-22 19:22 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-19 6:31 [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
2017-05-19 6:34 ` [Buildroot] Xorg and buildroot ? Riko Ho
2017-05-19 7:08 ` Thomas Petazzoni
2017-05-19 19:44 ` [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18 Thomas Petazzoni
2017-05-19 20:39 ` Yann E. MORIN
2017-05-20 7:03 ` Peter Seiderer
2017-05-20 10:10 ` Romain Naour
2017-05-22 19:22 ` Alexey Brodkin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.