From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Bill Randle <william.c.randle@intel.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [PATCHv3] man: fix several annoying compile/build warnings
Date: Wed, 30 Mar 2016 11:56:20 +0100 [thread overview]
Message-ID: <1459335380.21672.51.camel@linuxfoundation.org> (raw)
In-Reply-To: <1459323169.21672.46.camel@linuxfoundation.org>
On Wed, 2016-03-30 at 08:32 +0100, Richard Purdie wrote:
> On Tue, 2016-03-29 at 15:27 -0700, Bill Randle wrote:
> > Fixed the build error when building man.config.5 (a remnant of a
> > long
> > ago previous patch). Optimized the manpages Makefile for parallel
> > builds. Drop a FHS patch that is no longer needed, as the standard
> > Makefile puts the man pages in the proper location. Also, fix
> > compile
> > warnings in a couple other files.
> >
> > [YOCTO #9341]
> >
> > Signed-off-by: Bill Randle <william.c.randle@intel.com>
> > ---
> > [Note: should be applied after previous man patch "fix src/Makefile
> > to work with parallel make".]
> >
> > v3: clean up patch submission for mailing list
>
> These two were applied in the build yet we saw:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/bu
> il
> ds/718/steps/BuildImages/logs/stdio
The man failure worried me a bit so I had a look at the code. The
configure script looks good with its BUILD_CC and CC, however it goes
on to build things with $CC then run them which in a cross environment,
isn't going to work.
The reason we only saw failures in qemux86-64 with poky-lsb is because
that is the only case where the binaries generated with $CC could
actually run (in the normal poky case, the interpretor isn't in /lib64/
but /lib/).
On my local builds in conf_script I see:
s,@DEFS@, -DUSG -Duid_t=__uid_t -Dgid_t=__uid_t -DALLOCA_MISSING -DNONLS -DNOGETOPT -DDO_COMPRESS,
and on the failed builds on the AB:
s,@DEFS@, -DSTDC_HEADERS -DTERMIOS_HEADER -DPOSIX -DDO_COMPRESS,
with the -DNONLS being necessary to avoid build failures.
I suspect we're going to have to seriously patch the configure script
to remove several of the tests and then set the options to the correct
things manually.
I haven't looked further at what other nastiness may lurk beyond this
but at least we have a clear understanding of why its breaking now...
Cheers,
Richard
prev parent reply other threads:[~2016-03-30 10:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 22:27 [PATCHv3] man: fix several annoying compile/build warnings Bill Randle
2016-03-30 7:32 ` Richard Purdie
2016-03-30 10:56 ` Richard Purdie [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=1459335380.21672.51.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=william.c.randle@intel.com \
/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.