All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Mitchell <ml@communistcode.co.uk>
To: openembedded-devel@lists.openembedded.org
Subject: Re: tcpdump: bitbake throws autoconf errors, error message confusing
Date: Fri, 04 Jul 2014 13:09:29 +0100	[thread overview]
Message-ID: <53B69979.9040907@communistcode.co.uk> (raw)
In-Reply-To: <53B68266.4020503@communistcode.co.uk>

On 04/07/14 11:31, Jack Mitchell wrote:
> Hi Robert,
> 
> After further investigation that is also what I found, and why it's so
> confusing. The different tcpdump is because I uprevved to the latest
> version locally to see if it fixed the issue ;)
> 
> I'll see if I can figure out why the class if flagging it as bad when it
> shouldn't.
> 
> On 04/07/14 11:14, Robert Yang wrote:
>>
>> The error message comes from meta/classes/insane.bbclass:
>>
>> grep -e 'CROSS COMPILE Badness:' -e 'is unsafe for cross-compilation'
>>
>> The log you showed didn't contain the words, so that it should not error,
>> maybe you have to debug in meta/classes/insane.bbclass.
>>
>> Btw., the meta-oe's tcpdump is 4.3.0, yours is 4.5.1, maybe there are
>> other differences, for example you have used another insane.bbclass ?
>> (Just a guess)
>>
>> // Robert
>>
>> On 07/04/2014 05:42 PM, Jack Mitchell wrote:
>>> So tcpdump is failing to build in my latest uprev to all things HEAD.
>>> The error message is a touch cryptic:
>>>
>>> ERROR: This autoconf log indicates errors, it looked at host include
>>> and/or library paths while determining system capabilities.
>>> Rerun configure task after fixing this. The path was
>>> '/home/jack/Work/oe-core.git/test-build/tmp-eglibc/work/core2-32-oe-linux/tcpdump/4.5.1-r0/build'
>>>
>>> ERROR: Function failed: do_qa_configure
>>>
>>> log: http://ix.io/dg9
>>>
>>> Looking at the log I can't see where that specific path is used... can
>>> anyone shed any light?
>>>
>>> Cheers,
>>>
> 
> 

Ok, so I've found the issue. tcpdump finds some pcap binaries it needs
in the host sysroot, which then provides links to host include paths and
as such, the failure.

The question, how do I fix it? Will I need to inherit native or
something like that, so a local version is built which then points to
the correct sysroot that the cross version can then make use of? I've
never really had to deal with anything like this before...

config.log: http://ix.io/dgf

Regards,

-- 
  Jack Mitchell (jack@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 


      parent reply	other threads:[~2014-07-04 12:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04  9:42 tcpdump: bitbake throws autoconf errors, error message confusing Jack Mitchell
2014-07-04 10:14 ` Robert Yang
2014-07-04 10:31   ` Jack Mitchell
2014-07-04 12:08     ` Andrea Adami
2014-07-04 12:09     ` Jack Mitchell [this message]

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=53B69979.9040907@communistcode.co.uk \
    --to=ml@communistcode.co.uk \
    --cc=openembedded-devel@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.