[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Thomas Petazzoni]

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

[Buildroot] Xorg and buildroot ?

[Riko Ho]

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>

[Buildroot] Xorg and buildroot ?

[Thomas Petazzoni]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Thomas Petazzoni]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Peter Seiderer]

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

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Romain Naour]

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
> 

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-18

[Alexey Brodkin]

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