[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Thomas Petazzoni]

Build statistics for 2014-05-22
===============================

        success : 107
       failures : 11 
       timeouts : 0  
          TOTAL : 118

Classification of failures by reason
====================================

                 httping-2.3.4 | 1 
                      qt-4.8.6 | 1 
               alsa-lib-1.0.26 | 1 
                 mplayer-1.1.1 | 1 
               audiofile-0.3.6 | 1 
                    php-5.5.12 | 1 
             dosfstools-3.0.26 | 1 
                  python-2.7.6 | 1 
                  cppcms-1.0.4 | 1 
package/rpi-userland/rpi-us... | 1 
              gst1-libav-1.2.4 | 1 

Detail of failures
===================

   powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/520606ec674f6c8efad6ebbb840099ec89d03130/
    x86_64 |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/cc21623fbc3d4e94f09b2cb0be36ce05cf75a2e6/
   powerpc |                   cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/6a6eca78e0f8d730de612ed440ca5d030b363c12/
    mipsel |              dosfstools-3.0.26 | NOK | http://autobuild.buildroot.net/results/246c067f1e9def748498f0c6fa6988c036e1d109/
     avr32 |               gst1-libav-1.2.4 | NOK | http://autobuild.buildroot.net/results/ec6675adad4e09d71d7e365c399172ff233107f3/
   powerpc |                  httping-2.3.4 | NOK | http://autobuild.buildroot.net/results/365d6be787c5560aa1daa28065668261e1171d24/
       arc |                  mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/f62ace7ba49d492ea224bb8f3beb547389aab517/
       arm | package/rpi-userland/rpi-us... | NOK | http://autobuild.buildroot.net/results/0ef46e5d60c55387416c3293da8f26770854e158/
       arm |                     php-5.5.12 | NOK | http://autobuild.buildroot.net/results/3545a3a45124ef4f2c4c420ed56d0c923e3d63eb/
     avr32 |                   python-2.7.6 | NOK | http://autobuild.buildroot.net/results/4b42887bc7739447dd299361070e3625c3de7a56/
  mips64el |                       qt-4.8.6 | NOK | http://autobuild.buildroot.net/results/14309cd2c14f6a41f30cd00f7aef199b11612a85/


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Fabio Porcedda]

On Fri, May 23, 2014 at 8:30 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Build statistics for 2014-05-22
> ===============================
>
>         success : 107
>        failures : 11
>        timeouts : 0
>           TOTAL : 118
>
> Classification of failures by reason
> ====================================
>
>                  httping-2.3.4 | 1
>                       qt-4.8.6 | 1
>                alsa-lib-1.0.26 | 1
>                  mplayer-1.1.1 | 1
>                audiofile-0.3.6 | 1
>                     php-5.5.12 | 1
>              dosfstools-3.0.26 | 1
>                   python-2.7.6 | 1
>                   cppcms-1.0.4 | 1
> package/rpi-userland/rpi-us... | 1
>               gst1-libav-1.2.4 | 1
>
> Detail of failures
> ===================
>
>    powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/520606ec674f6c8efad6ebbb840099ec89d03130/
>     x86_64 |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/cc21623fbc3d4e94f09b2cb0be36ce05cf75a2e6/

It's related to BR2_PREFER_STATIC_LIB=y, I'm trying to fix it.

Regards
-- 
Fabio Porcedda

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Thomas Petazzoni]

Dear Fabio Porcedda,

On Fri, 23 May 2014 11:32:28 +0200, Fabio Porcedda wrote:

> >    powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/520606ec674f6c8efad6ebbb840099ec89d03130/
> >     x86_64 |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/cc21623fbc3d4e94f09b2cb0be36ce05cf75a2e6/
> 
> It's related to BR2_PREFER_STATIC_LIB=y, I'm trying to fix it.

Please note that Gustavo has already done a lot of investigation on
this one. It boils done to the fact that we pass --static instead of
-static when building statically. But we switched from -static to
--static a while ago, for some reason that the commit doesn't make
really clear.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Arnout Vandecappelle]

On 23/05/14 19:08, Thomas Petazzoni wrote:
> Dear Fabio Porcedda,
> 
> On Fri, 23 May 2014 11:32:28 +0200, Fabio Porcedda wrote:
> 
>>>    powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/520606ec674f6c8efad6ebbb840099ec89d03130/
>>>     x86_64 |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/cc21623fbc3d4e94f09b2cb0be36ce05cf75a2e6/
>>
>> It's related to BR2_PREFER_STATIC_LIB=y, I'm trying to fix it.
> 
> Please note that Gustavo has already done a lot of investigation on
> this one. It boils done to the fact that we pass --static instead of
> -static when building statically. But we switched from -static to
> --static a while ago, for some reason that the commit doesn't make
> really clear.

 I remember that: libtool will parse the -static option and act accordingly.
Only, it interprets it differently than gcc: it will only link statically
against local libraries, not against installed libraries. If we don't have any
.so files in $(STAGING_DIR), that wouldn't be a problem because it would still
link statically (no other option). But unfortunately there are still quite a few
packages that do install .so files in $(STAGING_DIR) - e.g. toolchain-external.
So without the --static, you end up with a lot of dynamically linked programs.

 For reference, the commit is 0a4bd19f4.

 As that commit mentions, we would actually like to pass -all-static to libtool.
But of course, that option is not known by gcc, so it won't work if libtool is
not used...

 A proper solution would be to adapt our libtool patches to interpret -static as
-all-static. Or alternatively, to patch the compiler wrapper to interpret
-all-static as -static (and then of course we'd have to generalize the compiler
wrapper to also use it for internal toolchains).

 If someone writes a patch, put me in Cc and I'll test it on a static
allpackageyesconfig.

 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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Yann E. MORIN]

Arnout, All,

On 2014-05-28 08:10 +0200, Arnout Vandecappelle spake thusly:
> On 23/05/14 19:08, Thomas Petazzoni wrote:
> > Dear Fabio Porcedda,
> > 
> > On Fri, 23 May 2014 11:32:28 +0200, Fabio Porcedda wrote:
> > 
> >>>    powerpc |                alsa-lib-1.0.26 | NOK | http://autobuild.buildroot.net/results/520606ec674f6c8efad6ebbb840099ec89d03130/
> >>>     x86_64 |                audiofile-0.3.6 | NOK | http://autobuild.buildroot.net/results/cc21623fbc3d4e94f09b2cb0be36ce05cf75a2e6/
> >>
> >> It's related to BR2_PREFER_STATIC_LIB=y, I'm trying to fix it.
> > 
> > Please note that Gustavo has already done a lot of investigation on
> > this one. It boils done to the fact that we pass --static instead of
> > -static when building statically. But we switched from -static to
> > --static a while ago, for some reason that the commit doesn't make
> > really clear.
> 
>  I remember that: libtool will parse the -static option and act accordingly.
> Only, it interprets it differently than gcc: it will only link statically
> against local libraries, not against installed libraries. If we don't have any
> .so files in $(STAGING_DIR), that wouldn't be a problem because it would still
> link statically (no other option).

Ah, yes, *that* libtool magic... :-/

> But unfortunately there are still quite a few
> packages that do install .so files in $(STAGING_DIR) - e.g. toolchain-external.
> So without the --static, you end up with a lot of dynamically linked programs.

So, what about a post-staging-install hook that would remove all .so
files with BR2_STATIC_ONLY?  (He!, a new name!)

>  For reference, the commit is 0a4bd19f4.
> 
>  As that commit mentions, we would actually like to pass -all-static to libtool.
> But of course, that option is not known by gcc, so it won't work if libtool is
> not used...

What about passing both -static and --static?

>  A proper solution would be to adapt our libtool patches to interpret -static as
> -all-static. Or alternatively, to patch the compiler wrapper to interpret
> -all-static as -static (and then of course we'd have to generalize the compiler
> wrapper to also use it for internal toolchains).

Yes, I think this is a good idea. But we can't use the wrapper to build
the toolchain itself, of course.

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 2014-05-22

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 28 May 2014 08:30:24 +0200, Yann E. MORIN wrote:

> >  A proper solution would be to adapt our libtool patches to interpret -static as
> > -all-static. Or alternatively, to patch the compiler wrapper to interpret
> > -all-static as -static (and then of course we'd have to generalize the compiler
> > wrapper to also use it for internal toolchains).
> 
> Yes, I think this is a good idea. But we can't use the wrapper to build
> the toolchain itself, of course.

And there is no wrapper at all when we use the internal toolchain
backend. At least as of today.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Yann E. MORIN]

Thomas, All,

On 2014-05-28 08:43 +0200, Thomas Petazzoni spake thusly:
> Dear Yann E. MORIN,
> 
> On Wed, 28 May 2014 08:30:24 +0200, Yann E. MORIN wrote:
> 
> > >  A proper solution would be to adapt our libtool patches to interpret -static as
> > > -all-static. Or alternatively, to patch the compiler wrapper to interpret
> > > -all-static as -static (and then of course we'd have to generalize the compiler
> > > wrapper to also use it for internal toolchains).
> > 
> > Yes, I think this is a good idea. But we can't use the wrapper to build
> > the toolchain itself, of course.
> 
> And there is no wrapper at all when we use the internal toolchain
> backend. At least as of today.

Hu? Of course we're not using the wrapper for internal toolchain. That's
why I replied it would be a good idea to use it (OK, I should have
trimmed the quote a bit more.)

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 2014-05-22

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 28 May 2014 08:47:06 +0200, Yann E. MORIN wrote:

> > > Yes, I think this is a good idea. But we can't use the wrapper to build
> > > the toolchain itself, of course.
> > 
> > And there is no wrapper at all when we use the internal toolchain
> > backend. At least as of today.
> 
> Hu? Of course we're not using the wrapper for internal toolchain. That's
> why I replied it would be a good idea to use it (OK, I should have
> trimmed the quote a bit more.)

Regarding using the wrapper for the internal toolchain, there's always
the problem of where we put the real toolchain binaries vs. the wrapper
binaries. For the external toolchain, it's simple: the real toolchain
binaries are in $(HOST_DIR)/opt/ext-toolchain, and the wrappers in
$(HOST_DIR)/usr/bin. But for the internal toolchain, we build/install
all the toolchain components with --prefix=$(HOST_DIR)/usr.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-22

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 > Regarding using the wrapper for the internal toolchain, there's always
 > the problem of where we put the real toolchain binaries vs. the wrapper
 > binaries. For the external toolchain, it's simple: the real toolchain
 > binaries are in $(HOST_DIR)/opt/ext-toolchain, and the wrappers in
 > $(HOST_DIR)/usr/bin. But for the internal toolchain, we build/install
 > all the toolchain components with --prefix=$(HOST_DIR)/usr.

Conceptually we could do something like

 --prefix=$(HOST_DIR)/usr \
 --bindir=$(HOST_DIR)/opt/raw-toolchain

But I haven't tried it.

-- 
Bye, Peter Korsgaard