* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 [not found] ` <20170411010019.GA2638@tungsten.ozlabs.ibm.com> @ 2017-04-11 12:43 ` Thomas Petazzoni 2017-04-12 9:51 ` Arnout Vandecappelle [not found] ` <20170412095212.1A18EB2050@b01ledav03.gho.pok.ibm.com> 0 siblings, 2 replies; 6+ messages in thread From: Thomas Petazzoni @ 2017-04-11 12:43 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 2017-04-11 12:43 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 Thomas Petazzoni @ 2017-04-12 9:51 ` Arnout Vandecappelle [not found] ` <20170412095212.1A18EB2050@b01ledav03.gho.pok.ibm.com> 1 sibling, 0 replies; 6+ messages in thread From: Arnout Vandecappelle @ 2017-04-12 9:51 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20170412095212.1A18EB2050@b01ledav03.gho.pok.ibm.com>]
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 [not found] ` <20170412095212.1A18EB2050@b01ledav03.gho.pok.ibm.com> @ 2017-04-13 5:34 ` Sam Bobroff 2017-04-13 22:14 ` Arnout Vandecappelle 0 siblings, 1 reply; 6+ messages in thread From: Sam Bobroff @ 2017-04-13 5:34 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 2017-04-13 5:34 ` Sam Bobroff @ 2017-04-13 22:14 ` Arnout Vandecappelle 2017-04-14 7:44 ` Thomas Petazzoni 0 siblings, 1 reply; 6+ messages in thread From: Arnout Vandecappelle @ 2017-04-13 22:14 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 2017-04-13 22:14 ` Arnout Vandecappelle @ 2017-04-14 7:44 ` Thomas Petazzoni 2017-04-14 17:04 ` Arnout Vandecappelle 0 siblings, 1 reply; 6+ messages in thread From: Thomas Petazzoni @ 2017-04-14 7:44 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 2017-04-14 7:44 ` Thomas Petazzoni @ 2017-04-14 17:04 ` Arnout Vandecappelle 0 siblings, 0 replies; 6+ messages in thread From: Arnout Vandecappelle @ 2017-04-14 17:04 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-14 17:04 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20170410062848.062C02803A@b01ledav001.gho.pok.ibm.com> [not found] ` <20170411010019.GA2638@tungsten.ozlabs.ibm.com> 2017-04-11 12:43 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2017-04-09 Thomas Petazzoni 2017-04-12 9:51 ` Arnout Vandecappelle [not found] ` <20170412095212.1A18EB2050@b01ledav03.gho.pok.ibm.com> 2017-04-13 5:34 ` Sam Bobroff 2017-04-13 22:14 ` Arnout Vandecappelle 2017-04-14 7:44 ` Thomas Petazzoni 2017-04-14 17:04 ` Arnout Vandecappelle
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.