From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2013-06-04
Date: Wed, 05 Jun 2013 20:52:49 +0200 [thread overview]
Message-ID: <87txlccrum.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20130605184836.6ea2b205@skate> (Thomas Petazzoni's message of "Wed, 5 Jun 2013 18:48:36 +0200")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Hello,
Thomas> On Wed, 5 Jun 2013 18:29:24 +0200, Thomas Petazzoni wrote:
>> > host-libftdi-0.19 | 20
>>
>> Those issues are caused by the bump of libtool, from the testing I
>> could do. Reverting libtool to the previous version "solves" the
>> problem.
>>
>> The thing that happens is that libftdi (for the target) has
>> AUTORECONF=YES, but not host-libftdi. So libftdi gets autoreconfigured,
>> and then when host-libftdi is being built, even though we don't have
>> AUTORECONF=YES, when starting the build, it does execute
>> 'CDPATH="${ZSH_VERSION+.}:" && cd .
>> && /bin/bash /home/test/outputs/libftdi/build/host-libftdi-0.19/missing
>> --run aclocal-1.11 ' and it ends up failing.
Thomas> Ok, the reason it does execute "missing" and does a kind of automatic
Thomas> autoreconf is because we have one patch that modifies configure.in. So
Thomas> configure.in is more recent than the configure script itself. When
Thomas> libtool/autoconf/automake has not been built before host-libftdi, then
Thomas> this automatic autoreconf cannot proceed:
That makes more sense. I didn't get how a target build (in a different
directory) could affect it.
So the fix is just HOST_LIBFTDI_AUTORECONF = YES?
Thomas> and it in facts makes the thing work.
Thomas> However, when this "automatic autoreconf" is done, and an
Thomas> automake/autoconf/libtool set of tools, with the latest libtool, has
Thomas> already been built and installed, then it generates some wrong stuff.
Thomas> An easy fix is to add:
Thomas> HOST_LIBFTDI_AUTORECONF = YES
Thomas> to libftdi.mk. It doesn't really explain why it was working with
Thomas> libtool 2.2 and no longer with libtool 2.4, but it works.
Indeed, odd. Well, having <pkg>_AUTORECONF = YES without
HOST_<pkg>_AUTORECONF = YES is obviously wrong, so let's just fix that.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2013-06-05 18:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2013-06-04 Thomas Petazzoni
2013-06-05 16:29 ` Thomas Petazzoni
2013-06-05 16:48 ` Thomas Petazzoni
2013-06-05 18:52 ` Peter Korsgaard [this message]
2013-06-05 17:00 ` Yann E. MORIN
2013-06-05 17:05 ` Gustavo Zacarias
2013-06-05 17:17 ` Yann E. MORIN
2013-06-05 18:00 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txlccrum.fsf@dell.be.48ers.dk \
--to=jacmet@uclibc.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.