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

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

[Thomas Petazzoni]

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

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Arnout Vandecappelle]

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.

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

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

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

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

[Sam Bobroff]

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.

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

[Arnout Vandecappelle]

On 13-04-17 07:34, Sam Bobroff wrote:
> On Wed, Apr 12, 2017 at 11:51:41AM +0200, Arnout Vandecappelle wrote:
>>
>>
>> On 11-04-17 14:43, Thomas Petazzoni wrote:
[snip]
>>> 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.)

 I don't think the rpath is wrong. For the target, it *is* indeed /usr/lib.
AFAIU the RPATH is *not* used as an extra -L equivalent at link time, except
when -rpath-link is given.


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

 Yes, Matt is looking at it.


> (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?

 Yes it would be nice to error out on circular dependencies. Also in Kconfig, by
the way.

 Our graph-depends detects circular dependencies in the Makefile, so we could
add it to autobuild-run (prior to the build).

 For Kconfig circular dependencies, I think we can only do string search. But
these are usually detected manually pretty quickly. And are also better detected
with a lot of 'make randconfig', that is going to show problems a lot sooner
than the autobuilders.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

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

[Thomas Petazzoni]

Hello,

On Fri, 14 Apr 2017 00:14:08 +0200, Arnout Vandecappelle wrote:

>  I don't think the rpath is wrong. For the target, it *is* indeed /usr/lib.
> AFAIU the RPATH is *not* used as an extra -L equivalent at link time, except
> when -rpath-link is given.

Not really clear to me what happens here. The ld documentation says:

     The linker uses the following search paths to locate required
     shared libraries:
       1. Any directories specified by '-rpath-link' options.
       2. Any directories specified by '-rpath' options.  The difference
          between '-rpath' and '-rpath-link' is that directories
          specified by '-rpath' options are included in the executable
          and used at runtime, whereas the '-rpath-link' option is only
          effective at link time.  Searching '-rpath' in this way is
          only supported by native linkers and cross linkers which have
          been configured with the '--with-sysroot' option.
       3. On an ELF system, for native linkers, if the '-rpath' and
          '-rpath-link' options were not used, search the contents of
          the environment variable 'LD_RUN_PATH'.
       4. On SunOS, if the '-rpath' option was not used, search any
          directories specified using '-L' options.
       5. For a native linker, search the contents of the environment
          variable 'LD_LIBRARY_PATH'.
       6. For a native ELF linker, the directories in 'DT_RUNPATH' or
          'DT_RPATH' of a shared library are searched for shared
          libraries needed by it.  The 'DT_RPATH' entries are ignored if
          'DT_RUNPATH' entries exist.
       7. The default directories, normally '/lib' and '/usr/lib'.
       8. For a native linker on an ELF system, if the file
          '/etc/ld.so.conf' exists, the list of directories found in
          that file.

But it's not clear if by "linker" they are talking about what "ld" is
doing at build time, or what "ld.so" is doing at runtime.

I've did a few experiments, building a dummy shared library and a
program that links to it:

thomas at skate:/tmp/toto$ ls
libtoto.so  libtoto.so.1  main.c  toto.c  toto.o

# -L allows the link to proceed

thomas at skate:/tmp/toto$ gcc -L/tmp/toto -o main main.c -ltoto
thomas at skate:/tmp/toto$ 

# Neither -rpath nor -rpath-link allows ld to find libtoto

thomas at skate:/tmp/toto$ gcc -Wl,-rpath,/tmp/toto -o main main.c -ltoto
/usr/bin/ld: cannot find -ltoto
collect2: error: ld returned 1 exit status

thomas at skate:/tmp/toto$ gcc -Wl,-rpath-link,/tmp/toto -o main main.c -ltoto
/usr/bin/ld: cannot find -ltoto
collect2: error: ld returned 1 exit status

# -L + -rpath, and you get the rpath encoded in the program

thomas at skate:/tmp/toto$ gcc -L/tmp/toto -Wl,-rpath,/tmp/toto -o main main.c -ltoto

thomas at skate:/tmp/toto$ readelf -d main| grep rpath
 0x000000000000000f (RPATH)              Library rpath: [/tmp/toto]

# -L + -rpath-link, and you don't get the rpath encoded in the program

thomas at skate:/tmp/toto$ gcc -L/tmp/toto -Wl,-rpath-link,/tmp/toto -o main main.c -ltoto
thomas at skate:/tmp/toto$ readelf -d main| grep rpath
thomas at skate:/tmp/toto$ 

> > (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?  
> 
>  Yes it would be nice to error out on circular dependencies. Also in Kconfig, by
> the way.
> 
>  Our graph-depends detects circular dependencies in the Makefile, so we could
> add it to autobuild-run (prior to the build).

Yes. The thing is that our "make graph-depends" target calls dot
unconditionally, and dot is not necessarily available on the autobuild
instances. So we need to call support/scripts/graph-depends directly
(which is definitely doable).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Arnout Vandecappelle]

On 14-04-17 09:44, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 14 Apr 2017 00:14:08 +0200, Arnout Vandecappelle wrote:
> 
>>  I don't think the rpath is wrong. For the target, it *is* indeed /usr/lib.
>> AFAIU the RPATH is *not* used as an extra -L equivalent at link time, except
>> when -rpath-link is given.
> 
> Not really clear to me what happens here. The ld documentation says:

 I was also pondering over that section and couldn't get to a conclusion :-)

[snip]
> I've did a few experiments, building a dummy shared library and a
> program that links to it:
> 
> thomas at skate:/tmp/toto$ ls
> libtoto.so  libtoto.so.1  main.c  toto.c  toto.o
> 
> # -L allows the link to proceed
> 
> thomas at skate:/tmp/toto$ gcc -L/tmp/toto -o main main.c -ltoto
> thomas at skate:/tmp/toto$ 
> 
> # Neither -rpath nor -rpath-link allows ld to find libtoto

 Great.

> 
> thomas at skate:/tmp/toto$ gcc -Wl,-rpath,/tmp/toto -o main main.c -ltoto
> /usr/bin/ld: cannot find -ltoto
> collect2: error: ld returned 1 exit status
> 
> thomas at skate:/tmp/toto$ gcc -Wl,-rpath-link,/tmp/toto -o main main.c -ltoto
> /usr/bin/ld: cannot find -ltoto
> collect2: error: ld returned 1 exit status
> 
> # -L + -rpath, and you get the rpath encoded in the program

 Of course.

> 
> thomas at skate:/tmp/toto$ gcc -L/tmp/toto -Wl,-rpath,/tmp/toto -o main main.c -ltoto
> 
> thomas at skate:/tmp/toto$ readelf -d main| grep rpath
>  0x000000000000000f (RPATH)              Library rpath: [/tmp/toto]
> 
> # -L + -rpath-link, and you don't get the rpath encoded in the program

 Doesn't matter, we don't use rpath-link :-)

> 
> thomas at skate:/tmp/toto$ gcc -L/tmp/toto -Wl,-rpath-link,/tmp/toto -o main main.c -ltoto
> thomas at skate:/tmp/toto$ readelf -d main| grep rpath
> thomas at skate:/tmp/toto$ 

 You're missing one important case here: when toto.so is linked with -rpath to
some /tmp/other directory which contains a library you link against, or that is
NEEDED by toto.

 And then there is also the question of the effect of --sysroot.

 Not to forget the evil that can be done by libtool.

 Sigh.
[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF