[Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09

Sam Bobroff sam.bobroff at au1.ibm.com
Thu Apr 13 05:34:06 UTC 2017


On Wed, Apr 12, 2017 at 11:51:41AM +0200, Arnout Vandecappelle wrote:
> 
> 
> On 11-04-17 14:43, Thomas Petazzoni wrote:
> > Hello,
> > 
> > Adding the Buildroot mailing in Cc, and therefore keeping the full
> > context.
> > 
> > On Tue, 11 Apr 2017 11:00:19 +1000, Sam Bobroff wrote:
> > 
> >> I had a look at this, but I'm not having much luck. Do you have any
> >> advice?
> >>
> >> The error itself is clear from the build log, both during configure and
> >> later at the link failure:
> >>
> >> From http://autobuild.buildroot.net/results/005/0050aa0d5360d166d07d4b6ee4484f4746b224f5/readline-7.0/config.log
> >>
> >> configure:6025: checking for tgetent in -lncurses
> >> configure:6050:
> >> /home/buildroot/build/instance-0/output/host/usr/bin/powerpc64-linux-gcc
> >> -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> >> -D_FILE_OFFSET_BITS=64  -Os  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> >> -D_FILE_OFFSET_BITS=64  conftest.c -lncurses   >&5
> >> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/5.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: cannot find -lncurses
> >>
> >> From http://autobuild.buildroot.net/results/005/0050aa0d5360d166d07d4b6ee4484f4746b224f5/build-end.log
> >>
> >> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/5.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: cannot find -lncurses
> >> collect2: error: ld returned 1 exit status
> >>
> >> (I do see why it's using ncurses even though it wasn't detected: the package
> >> file forces -lncurses into LIBS.)
> >>
> >> There are no references to ncurses in the build-time.log file, so it
> >> apparently wasn't built at all during this run.
> 
>  I suspect this is a circular dependency. Possibly
> 
> ncurses -> busybox -> libselinux -> python3 -> readline -> ncurses
> 
>  It would be nice to have the first 50 lines or so of the build log saved as
> well, then we would see such a circular dependency.

Hmm, I wondered about this and I agree: the first 50 or so lines (maybe
200? All of it? :-) How much is space an issue?) would be really useful.

And, I think you're on to the right track...

> >>
> >> But the package file for readline has "READLINE_DEPENDENCIES = ncurses"
> >> and "BR2_PACKAGE_NCURSES=y" *is* set in the Buildroot config.
> >>
> >> I can't replicate the failure locally, Buildroot always builds ncurses
> >> as I expect from that configuration.
> 
>  Did you use the same .config?

I tried, but unfortunately selinux failes to build (not sure when I'll
have time to look at that one; some linker error to do with -fPIC).

However, I *do* see a "Circular dependency dropped" message, which is
good confirmation for the theory above.

> >> So the only explanation I can think of is that the autobuilder's target
> >> directory is missing ncurses but the Buildroot stamp file must indicate
> >> that it's already been installed.
> >>
> >> Am I missing something?
> > 
> > There is a -Wl,-rpath,/usr/lib in the link command link that isn't
> > correct. This means that the compiler will try to link against the host
> > ncurses if available, which is bad.
> 
>  I suspect that that is there just because ncurses wasn't detected. But I could
> be wrong.

(I saw the bad rpath even on my successful builds -- I'll see if it's
easy to fix, since I'm looking at it anyway.)

So it seems fairly clear now: there is a circular dependency in that set
of packages and GNU make's behaviour is to drop a dependency and
continue building, so we end up building readline configured with
ncurses, with no ncurses, so it fails.

(IMHO this is very poor behaviour from GNU make: it seems to be
knowingly producing a broken build but exiting with success, and the
only indication is one fairly innocuous looking line of output. There is
no option to convert that warning into a fatal error! I even checked the
source :-( )

So, what do we do? It seems like it would be nice to catch any circular
dependency but is there any good way to do that? I don't like the idea
of running make under grep looking for "errors", or trying to manualy
detect circular dependencies either... Has this been explored already?

Thanks!
Sam.



More information about the buildroot mailing list