All of lore.kernel.org
 help / color / mirror / Atom feed
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
>



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