From: Hongxu Jia <hongxu.jia@windriver.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] autotools.bbclass: output failed config.log
Date: Wed, 15 May 2019 21:50:35 +0800 [thread overview]
Message-ID: <da1db475-e2ea-d474-e335-1c56285b9361@windriver.com> (raw)
In-Reply-To: <20190515134218.GA20396@localhost>
On 5/15/19 9:42 PM, Adrian Bunk wrote:
> On Wed, May 15, 2019 at 08:30:03PM +0800, Hongxu Jia wrote:
>> On 5/15/19 7:08 PM, Adrian Bunk wrote:
>>> The end of config.log often contains expected error messages completely
>>> unrelated to the actual problem.
>> I am afraid you did not suffer pain from it, the most related message
>>
>> with do_configure failure is config.log. Take a example, as my previous
>>
>> commit [grub/grub-efi: fix unrecognized command line option
>>
>> '-pipe-Wno-error' in CFLAGS]
>>
>> It takes me hours to reproduce grub/grub-efi build faiure (only
>> ...
> I fully understand your pain, and have already suffered it many times.
>
>>> Debian autobuilders already dump config.log when when configuring failed,
>>> and there it is a common problem that people end up searching for the
>>> problem in the wrong places due to that.
>> It's another story, it is better that autobuilder provide sufficient and
>>
>> necessary info and data, not only config.log, but also local.conf,
>>
>> all available log.do_***, sources in ${B} and ${S}, even data in ${WORKDIR},
>>
>> result of `bitbake -e'
>>
>> but before we got there, the fix is best choice for do_configure failure
> There is no universal best choice here.
>
> Let me give you an example when building a more recent ofono locally
> with and without your patch.
>
> When a configure task fails, the last lines from log.do_configure
> are dumped to the shell.
>
> Without your patch I get when building in a shell:
> ...
> | checking whether to build shared libraries... yes
> | checking whether to build static libraries... no
> | checking for signalfd... yes
> | checking for dlopen in -ldl... yes
> | checking for glib-2.0 >= 2.32... yes
> | checking for dbus-1 >= 1.4... yes
> | checking for libudev >= 143... yes
> | checking for mobile-broadband-provider-info... yes
> | checking for ell >= 0.12... no
> | configure: error: Embedded Linux library >= 0.12 is required
> ...
>
> The problem is immediately visible.
>
> With your patch, one has to scroll up through the whole config.log for
> getting this information.
>
> And the config.log contains plenty of other (expected) errors a user
> might mistake as cause of the problem.
>
> For autobuilders dumping config.log can be OK if there is no better
> option available, but people looking at autobuilder logs should be
> aware what to scroll over when starting to look at the log.
>
> For anyone building manually in a shell these should really not be done,
> it has a high potential of confuding the user and the config.log is
> easily available.
>
> The best available option might be to have a knob with default off,
> and autobuilders might be configured to dump config.log.
After applying my fix, here is the sample
...
checking for i586-wrs-linux-gcc... i586-wrs-linux-gcc -m32 -march=i586
--sysroot=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot
checking whether the C compiler works... no
configure: error: in
`/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build':
configure: error: C compiler cannot create executables
See `config.log' for more details
NOTE: The following config.log files may provide further information.
NOTE:
/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build/config.log
NOTE: This file contains any messages produced by compilers while
NOTE: running configure, to aid debugging if configure makes a mistake.
...
The content of config.log has prefix `NOTE:' and also tells user
See `config.log' for more dettails and balabala
//Hongxu
>> //Hongxu
> cu
> Adrian
>
next prev parent reply other threads:[~2019-05-15 13:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 9:23 [PATCH] autotools.bbclass: output failed config.log Hongxu Jia
2019-05-15 9:32 ` Andreas Müller
2019-05-15 9:50 ` Hongxu Jia
2019-05-15 10:54 ` Andreas Müller
2019-05-15 11:57 ` Hongxu Jia
2019-05-15 11:08 ` Adrian Bunk
2019-05-15 12:30 ` Hongxu Jia
2019-05-15 13:42 ` Adrian Bunk
2019-05-15 13:50 ` Hongxu Jia [this message]
2019-05-15 13:53 ` Hongxu Jia
2019-05-15 14:02 ` Adrian Bunk
2019-05-20 20:50 ` Khem Raj
2019-05-15 13:32 ` [PATCH V2] " Hongxu Jia
2019-05-15 14:01 ` richard.purdie
2019-05-15 14:05 ` Hongxu Jia
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=da1db475-e2ea-d474-e335-1c56285b9361@windriver.com \
--to=hongxu.jia@windriver.com \
--cc=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox