| Message ID | 20171030163121.939-1-norbert.lange@andritz.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [1/1] Fix build of lttng-libust | expand |
Hello, On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: > The build of doc/examples/cmake-multiple-shared-libraries > does fail as a dependend library is missing. > This issue is not specific to builroot and should ideally > be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) > > The fix is done without any indepth knowledge of the CMake > mechanisms, but seems to work correctly > > Signed-off-by: Norbert Lange <norbert.lange@andritz.com> Which specific build problem are you fixing? Is this a problem that has been found by http://autobuild.buildroot.org? If that's the case, we like to include a reference to such an autobuilder failure in the commit log. Thanks! Thomas
Hello Thomas, I dont know about the autobuilder (can I upload configs to test there?), this is an issue I encountered with a private buildroot config. I tried to reduce it as much as possible, and added the defconfig. 2017-10-30 20:40 GMT+01:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Hello, > > On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: >> The build of doc/examples/cmake-multiple-shared-libraries >> does fail as a dependend library is missing. >> This issue is not specific to builroot and should ideally >> be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) >> >> The fix is done without any indepth knowledge of the CMake >> mechanisms, but seems to work correctly >> >> Signed-off-by: Norbert Lange <norbert.lange@andritz.com> > > Which specific build problem are you fixing? Is this a problem that has > been found by http://autobuild.buildroot.org? If that's the case, we > like to include a reference to such an autobuilder failure in the > commit log. > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
On 31-10-17 11:20, Norbert Lange wrote: > Hello Thomas, > > I dont know about the autobuilder (can I upload configs to test > there?), this is an issue I encountered with a private buildroot > config. > I tried to reduce it as much as possible, and added the defconfig. > > 2017-10-30 20:40 GMT+01:00 Thomas Petazzoni > <thomas.petazzoni@free-electrons.com>: >> Hello, >> >> On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: >>> The build of doc/examples/cmake-multiple-shared-libraries >>> does fail as a dependend library is missing. >>> This issue is not specific to builroot and should ideally >>> be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) >>> >>> The fix is done without any indepth knowledge of the CMake >>> mechanisms, but seems to work correctly >>> >>> Signed-off-by: Norbert Lange <norbert.lange@andritz.com> >> >> Which specific build problem are you fixing? Is this a problem that has >> been found by http://autobuild.buildroot.org? If that's the case, we >> like to include a reference to such an autobuilder failure in the >> commit log. It has not been found by the autobuilders, the only failure is http://autobuild.buildroot.net/results/c86a82b2fd41316a7a451b20d9274d5c95f89baa and that's due to CMake version. The build error is: output/host/lib/gcc/x86_64-buildroot-linux-gnu/7.2.0/../../../../x86_64-buildroot-linux-gnu/bin/ld: warning: liblttng-ust-tracepoint.so.0, needed by output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link) output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `exit_tracepoint' output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `__tracepoint_probe_unregister_queue_release' output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `__tracepoint_probe_register_queue_release' output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `__tracepoint_probe_prune_release_queue' output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `init_tracepoint' collect2: error: ld returned 1 exit status The weird thing is: liblttng-ust.so.0 does have the correct RPATH to find the tracepoint library. And on all other builds I tried (and apparently including all the autobuilders), it does find it. So I guess it's either binutils 2.29 or GCC 7's LTO plugin that is acting up somehow... Since this is anyway just an example, wouldn't it be better to just disable the documentation entirely? I.e. teach configure.ac to understand --disable-doc and teach Makefile.am to not recurse into doc if docs are disabled? Regards, Arnout
Arnout, All, On 2017-11-05 17:13 +0100, Arnout Vandecappelle spake thusly: > On 31-10-17 11:20, Norbert Lange wrote: > > Hello Thomas, > > > > I dont know about the autobuilder (can I upload configs to test > > there?), this is an issue I encountered with a private buildroot > > config. > > I tried to reduce it as much as possible, and added the defconfig. > > > > 2017-10-30 20:40 GMT+01:00 Thomas Petazzoni > > <thomas.petazzoni@free-electrons.com>: > >> Hello, > >> > >> On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: > >>> The build of doc/examples/cmake-multiple-shared-libraries > >>> does fail as a dependend library is missing. > >>> This issue is not specific to builroot and should ideally > >>> be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) > >>> > >>> The fix is done without any indepth knowledge of the CMake > >>> mechanisms, but seems to work correctly > >>> > >>> Signed-off-by: Norbert Lange <norbert.lange@andritz.com> > >> > >> Which specific build problem are you fixing? Is this a problem that has > >> been found by http://autobuild.buildroot.org? If that's the case, we > >> like to include a reference to such an autobuilder failure in the > >> commit log. > > It has not been found by the autobuilders, the only failure is > http://autobuild.buildroot.net/results/c86a82b2fd41316a7a451b20d9274d5c95f89baa > and that's due to CMake version. But aren't we supposed to build our own host-cmake if the system cmake is tool old? And IIRC, we consider cmake < 3.1 to be too old: $ grep 3.1 support/dependencies/check-host-cmake.mk BR2_CMAKE_VERSION_MIN = 3.1 So in that case, we should have been using our own cmake, while the build log clearly state that was not the case: CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 2.8.11 or higher is required. You are running version 2.8.9 But lttng-libust is an autotools package, which explains why our host-cmake is not necessarily built. But I digress, and I think a better fix would indeed be to teach configure.ac and Makefile.am to disable building the examples. Regards, Yann E. MORIN. > The build error is: > > output/host/lib/gcc/x86_64-buildroot-linux-gnu/7.2.0/../../../../x86_64-buildroot-linux-gnu/bin/ld: > warning: liblttng-ust-tracepoint.so.0, needed by > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so, not found > (try using -rpath or -rpath-link) > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `exit_tracepoint' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `__tracepoint_probe_unregister_queue_release' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `__tracepoint_probe_register_queue_release' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `__tracepoint_probe_prune_release_queue' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `init_tracepoint' > collect2: error: ld returned 1 exit status > > The weird thing is: liblttng-ust.so.0 does have the correct RPATH to find the > tracepoint library. And on all other builds I tried (and apparently including > all the autobuilders), it does find it. So I guess it's either binutils 2.29 or > GCC 7's LTO plugin that is acting up somehow... > > > Since this is anyway just an example, wouldn't it be better to just disable the > documentation entirely? I.e. teach configure.ac to understand --disable-doc and > teach Makefile.am to not recurse into doc if docs are disabled? > > 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 mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
On Sun, Nov 5, 2017 at 11:31 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > Arnout, All, > > On 2017-11-05 17:13 +0100, Arnout Vandecappelle spake thusly: > > On 31-10-17 11:20, Norbert Lange wrote: > > > Hello Thomas, > > > > > > I dont know about the autobuilder (can I upload configs to test > > > there?), this is an issue I encountered with a private buildroot > > > config. > > > I tried to reduce it as much as possible, and added the defconfig. > > > > > > 2017-10-30 20:40 GMT+01:00 Thomas Petazzoni > > > <thomas.petazzoni@free-electrons.com>: > > >> Hello, > > >> > > >> On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: > > >>> The build of doc/examples/cmake-multiple-shared-libraries > > >>> does fail as a dependend library is missing. > > >>> This issue is not specific to builroot and should ideally > > >>> be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) > > >>> > > >>> The fix is done without any indepth knowledge of the CMake > > >>> mechanisms, but seems to work correctly > > >>> > > >>> Signed-off-by: Norbert Lange <norbert.lange@andritz.com> > > >> > > >> Which specific build problem are you fixing? Is this a problem that has > > >> been found by http://autobuild.buildroot.org? If that's the case, we > > >> like to include a reference to such an autobuilder failure in the > > >> commit log. > > > > It has not been found by the autobuilders, the only failure is > > http://autobuild.buildroot.net/results/c86a82b2fd41316a7a451b20d9274d5c95f89baa > > and that's due to CMake version. > > But aren't we supposed to build our own host-cmake if the system cmake > is tool old? And IIRC, we consider cmake < 3.1 to be too old: > > $ grep 3.1 support/dependencies/check-host-cmake.mk > BR2_CMAKE_VERSION_MIN = 3.1 > > So in that case, we should have been using our own cmake, while the > build log clearly state that was not the case: > > CMake Error at CMakeLists.txt:1 (cmake_minimum_required): > CMake 2.8.11 or higher is required. You are running version 2.8.9 > > But lttng-libust is an autotools package, which explains why our > host-cmake is not necessarily built. > > But I digress, and I think a better fix would indeed be to teach > configure.ac and Makefile.am to disable building the examples. I'll have a look at what we can do upstream for this. Phil > > Regards, > Yann E. MORIN. > > > The build error is: > > > > output/host/lib/gcc/x86_64-buildroot-linux-gnu/7.2.0/../../../../x86_64-buildroot-linux-gnu/bin/ld: > > warning: liblttng-ust-tracepoint.so.0, needed by > > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so, not found > > (try using -rpath or -rpath-link) > > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > > reference to `exit_tracepoint' > > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > > reference to `__tracepoint_probe_unregister_queue_release' > > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > > reference to `__tracepoint_probe_register_queue_release' > > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > > reference to `__tracepoint_probe_prune_release_queue' > > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > > reference to `init_tracepoint' > > collect2: error: ld returned 1 exit status > > > > The weird thing is: liblttng-ust.so.0 does have the correct RPATH to find the > > tracepoint library. And on all other builds I tried (and apparently including > > all the autobuilders), it does find it. So I guess it's either binutils 2.29 or > > GCC 7's LTO plugin that is acting up somehow... > > > > > > Since this is anyway just an example, wouldn't it be better to just disable the > > documentation entirely? I.e. teach configure.ac to understand --disable-doc and > > teach Makefile.am to not recurse into doc if docs are disabled? > > > > 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 mailing list > > buildroot@busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------'
2017-11-05 17:13 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: > > > On 31-10-17 11:20, Norbert Lange wrote: >> Hello Thomas, >> >> I dont know about the autobuilder (can I upload configs to test >> there?), this is an issue I encountered with a private buildroot >> config. >> I tried to reduce it as much as possible, and added the defconfig. >> >> 2017-10-30 20:40 GMT+01:00 Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com>: >>> Hello, >>> >>> On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: >>>> The build of doc/examples/cmake-multiple-shared-libraries >>>> does fail as a dependend library is missing. >>>> This issue is not specific to builroot and should ideally >>>> be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) >>>> >>>> The fix is done without any indepth knowledge of the CMake >>>> mechanisms, but seems to work correctly >>>> >>>> Signed-off-by: Norbert Lange <norbert.lange@andritz.com> >>> >>> Which specific build problem are you fixing? Is this a problem that has >>> been found by http://autobuild.buildroot.org? If that's the case, we >>> like to include a reference to such an autobuilder failure in the >>> commit log. > > It has not been found by the autobuilders, the only failure is > http://autobuild.buildroot.net/results/c86a82b2fd41316a7a451b20d9274d5c95f89baa > and that's due to CMake version. So, is that a problem, or even something I should do anything about? I am not sure why you bring this up repeatedly. > > The build error is: > > output/host/lib/gcc/x86_64-buildroot-linux-gnu/7.2.0/../../../../x86_64-buildroot-linux-gnu/bin/ld: > warning: liblttng-ust-tracepoint.so.0, needed by > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so, not found > (try using -rpath or -rpath-link) > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `exit_tracepoint' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `__tracepoint_probe_unregister_queue_release' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `__tracepoint_probe_register_queue_release' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `__tracepoint_probe_prune_release_queue' > output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined > reference to `init_tracepoint' > collect2: error: ld returned 1 exit status So I take, you can reproduce it. > > The weird thing is: liblttng-ust.so.0 does have the correct RPATH to find the > tracepoint library. And on all other builds I tried (and apparently including > all the autobuilders), it does find it. So I guess it's either binutils 2.29 or > GCC 7's LTO plugin that is acting up somehow... LTO doesn't seem involved (I think?) > > > Since this is anyway just an example, wouldn't it be better to just disable the > documentation entirely? I.e. teach configure.ac to understand --disable-doc and > teach Makefile.am to not recurse into doc if docs are disabled? No problem with that, for the upstream package this might be more of an issue. I am certainly curious where this issue comes from, and what other problems could be showing up. Whether this is a lttng, CMake, gcc or binutils issue... > > 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
Philippe, All, On 2017-11-05 22:10 +0100, Yann E. MORIN spake thusly: > On 2017-11-05 14:55 -0500, Philippe Proulx spake thusly: > > On Sun, Nov 5, 2017 at 11:31 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > [--SNIP--] > > > But I digress, and I think a better fix would indeed be to teach > > > configure.ac and Makefile.am to disable building the examples. > > I'll have a look at what we can do upstream for this. > > Here is a very quick-n-dirty patch against your master, that should do > the trick (but is totally untested). Feel free to use it as-is if you > like it. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > > diff --git a/configure.ac b/configure.ac > index ca1de874..adbd8f90 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -468,6 +468,19 @@ they will not be installed. > AM_CONDITIONAL([MAN_PAGES_OPT], [test "x$man_pages_opt" != "xno"]) > AM_CONDITIONAL([HAVE_ASCIIDOC_XMLTO], [test "x$have_asciidoc_xmlto" = "xyes"]) > > +# Do we want to build example? > +AC_ARG_ENABLE( > +examples, > +AS_HELP_STRING( > +[--d isable-examples], > +[Do not build examples] > +), > +[examples_opt=$enab leval], > +[examples_opt=yes] > +) > + > +AM_CONDITIONAL([EXAMPLES_OPT], [test "x$examples_opt" != "xno"]) Damned, this was badly mangled... :-( et ft= diff --git a/configure.ac b/configure.ac index ca1de874..adbd8f90 100644 --- a/configure.ac +++ b/configure.ac @@ -468,6 +468,19 @@ they will not be installed. AM_CONDITIONAL([MAN_PAGES_OPT], [test "x$man_pages_opt" != "xno"]) AM_CONDITIONAL([HAVE_ASCIIDOC_XMLTO], [test "x$have_asciidoc_xmlto" = "xyes"]) +# Do we want to build examples? +AC_ARG_ENABLE( + examples, + AS_HELP_STRING( + [--disable-examples], + [Do not build examples] + ), + [examples_opt=$enableval], + [examples_opt=yes] +) + +AM_CONDITIONAL([EXAMPLES_OPT], [test "x$examples_opt" != "xno"]) + # Default values AC_DEFUN([_AC_DEFINE_AND_SUBST], [ AC_DEFINE_UNQUOTED([CONFIG_$1], [$2], [$1]) diff --git a/doc/Makefile.am b/doc/Makefile.am index e110ed85..82689c5c 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,3 +1,7 @@ -SUBDIRS = . man examples +if EXAMPLES_OPT +EXAMPLES_SUBDIRS = examples +endif + +SUBDIRS = . man $(EXAMPLES_SUBDIRS) dist_doc_DATA = java-agent.txt > # Default values > AC_DEFUN([_AC_DEFINE_AND_SUBST], [ > AC_DEFINE_UNQUOTED([CONFIG_$1], [$2], [$1]) > diff --git a/doc/Makefile.am b/doc/Makefile.am > index e110ed85..82689c5c 100644 > --- a/doc/Makefile.am > +++ b/doc/Makefile.am > @@ -1,3 +1,7 @@ > -SUBDIRS = . man examples > +if EXAMPLES_OPT > +EXAMPLES_SUBDIRS = examples > +endif > + > +SUBDIRS = . man $(EXAMPLES_SUBDIRS) > > dist_doc_DATA = java-agent.txt > > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------' > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
On 05-11-17 21:36, Norbert Lange wrote: > 2017-11-05 17:13 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: >> >> >> On 31-10-17 11:20, Norbert Lange wrote: >>> Hello Thomas, >>> >>> I dont know about the autobuilder (can I upload configs to test >>> there?), this is an issue I encountered with a private buildroot >>> config. >>> I tried to reduce it as much as possible, and added the defconfig. >>> >>> 2017-10-30 20:40 GMT+01:00 Thomas Petazzoni >>> <thomas.petazzoni@free-electrons.com>: >>>> Hello, >>>> >>>> On Mon, 30 Oct 2017 17:31:21 +0100, Norbert Lange wrote: >>>>> The build of doc/examples/cmake-multiple-shared-libraries >>>>> does fail as a dependend library is missing. >>>>> This issue is not specific to builroot and should ideally >>>>> be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) >>>>> >>>>> The fix is done without any indepth knowledge of the CMake >>>>> mechanisms, but seems to work correctly >>>>> >>>>> Signed-off-by: Norbert Lange <norbert.lange@andritz.com> >>>> >>>> Which specific build problem are you fixing? Is this a problem that has >>>> been found by http://autobuild.buildroot.org? If that's the case, we >>>> like to include a reference to such an autobuilder failure in the >>>> commit log. >> >> It has not been found by the autobuilders, the only failure is >> http://autobuild.buildroot.net/results/c86a82b2fd41316a7a451b20d9274d5c95f89baa >> and that's due to CMake version. > > So, is that a problem, or even something I should do anything about? > I am not sure why you bring this up repeatedly. Ah yes sorry, we didn't explain about the autobuilders. The autobuilders do continuous builds of random configurations, and upload the result of those builds to http://autobuild.buildroot.org. Usually if a package fails to build in some circumstances, it is detected by these random builds. In this case, it is not detected. So the issue must be caused by something that is not covered by these random configurations. Since LTO is one of the aspects that doesn't get tested, I thought that that could be the trigger. Now I noticed however that the defconfig you sent also contains BR2_SHARED_STATIC_LIBS=y and that's a much more likely trigger (it is also not covered by the autobuilders). Hm, I retested a different config (with a prebuilt toolchain so it builds faster) with this option enabled and that does work. So maybe it's LTO after all. >> The build error is: >> >> output/host/lib/gcc/x86_64-buildroot-linux-gnu/7.2.0/../../../../x86_64-buildroot-linux-gnu/bin/ld: >> warning: liblttng-ust-tracepoint.so.0, needed by >> output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so, not found >> (try using -rpath or -rpath-link) >> output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined >> reference to `exit_tracepoint' >> output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined >> reference to `__tracepoint_probe_unregister_queue_release' >> output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined >> reference to `__tracepoint_probe_register_queue_release' >> output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined >> reference to `__tracepoint_probe_prune_release_queue' >> output/build/lttng-libust-2.9.0/liblttng-ust/.libs/liblttng-ust.so: undefined >> reference to `init_tracepoint' >> collect2: error: ld returned 1 exit status > > So I take, you can reproduce it. Indeed, with the defconfig you sent before it can be reproduced. >> >> The weird thing is: liblttng-ust.so.0 does have the correct RPATH to find the >> tracepoint library. And on all other builds I tried (and apparently including >> all the autobuilders), it does find it. So I guess it's either binutils 2.29 or >> GCC 7's LTO plugin that is acting up somehow... > > LTO doesn't seem involved (I think?) Well, selecting the same packages and using one of the prebuilt toolchains does *not* trigger this issue, so it must be one of the toolchain options. >> Since this is anyway just an example, wouldn't it be better to just disable the >> documentation entirely? I.e. teach configure.ac to understand --disable-doc and >> teach Makefile.am to not recurse into doc if docs are disabled? > > No problem with that, for the upstream package this might be more of an issue. Philippe (one of the upstream developers) already said that he'd look into it. > I am certainly curious where this issue comes from, and what other problems > could be showing up. Whether this is a lttng, CMake, gcc or binutils issue... For upstream it's obviously interesting to find the underlying issue, but for Buildroot it's not relevant since it's only an example. It gets installed in /usr/share/doc and that directory is removed in target-finalize. Regards, Arnout
On Sun, Nov 5, 2017 at 5:02 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > > >>> Since this is anyway just an example, wouldn't it be better to just disable the >>> documentation entirely? I.e. teach configure.ac to understand --disable-doc and >>> teach Makefile.am to not recurse into doc if docs are disabled? >> >> No problem with that, for the upstream package this might be more of an issue. > > Philippe (one of the upstream developers) already said that he'd look into it. > It's in master now, hope it helps: <https://github.com/lttng/lttng-ust/commit/08aa9a26779d4ede3de7857fafd03bd6331ba948>. Phil >> I am certainly curious where this issue comes from, and what other problems >> could be showing up. Whether this is a lttng, CMake, gcc or binutils issue... > For upstream it's obviously interesting to find the underlying issue, but for > Buildroot it's not relevant since it's only an example. It gets installed in > /usr/share/doc and that directory is removed in target-finalize. > > 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
Hello, On Mon, 6 Nov 2017 16:06:10 -0500, Philippe Proulx wrote: > > > >>> Since this is anyway just an example, wouldn't it be better to just disable the > >>> documentation entirely? I.e. teach configure.ac to understand --disable-doc and > >>> teach Makefile.am to not recurse into doc if docs are disabled? > >> > >> No problem with that, for the upstream package this might be more of an issue. > > > > Philippe (one of the upstream developers) already said that he'd look into it. > > > > It's in master now, hope it helps: > <https://github.com/lttng/lttng-ust/commit/08aa9a26779d4ede3de7857fafd03bd6331ba948>. Thanks! While you're at it, do you think you could also have a look at http://autobuild.buildroot.net/results/f46/f46ba3cc8bf3ce979e9391db05780476cbba6ea0/build-end.log ? I reported it on the lttng mailing list a loooong time ago, and never got any feedback. It also happens with musl: http://autobuild.buildroot.net/results/99b/99bfee5ccd45c945bd607c3a8c0f972338133efc/build-end.log. Thanks! Thomas
On Mon, Nov 6, 2017 at 4:12 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Mon, 6 Nov 2017 16:06:10 -0500, Philippe Proulx wrote: > >> > >> >>> Since this is anyway just an example, wouldn't it be better to just disable the >> >>> documentation entirely? I.e. teach configure.ac to understand --disable-doc and >> >>> teach Makefile.am to not recurse into doc if docs are disabled? >> >> >> >> No problem with that, for the upstream package this might be more of an issue. >> > >> > Philippe (one of the upstream developers) already said that he'd look into it. >> > >> >> It's in master now, hope it helps: >> <https://github.com/lttng/lttng-ust/commit/08aa9a26779d4ede3de7857fafd03bd6331ba948>. > > Thanks! > > While you're at it, do you think you could also have a look at > http://autobuild.buildroot.net/results/f46/f46ba3cc8bf3ce979e9391db05780476cbba6ea0/build-end.log ? > I reported it on the lttng mailing list a loooong time ago, and never > got any feedback. > > It also happens with musl: > http://autobuild.buildroot.net/results/99b/99bfee5ccd45c945bd607c3a8c0f972338133efc/build-end.log. Yes, I know how to fix this. I'll have a look at it. We need to check for dlmopen()'s support in configure.ac (like we do in LTTng-UST) and conditionally build parts of the test depending on the result. Phil > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
diff --git a/package/lttng-libust/0005_fix_build.patch b/package/lttng-libust/0005_fix_build.patch new file mode 100644 index 0000000000..96be80aaa6 --- /dev/null +++ b/package/lttng-libust/0005_fix_build.patch @@ -0,0 +1,28 @@ +diff -burN lttng-ust-2.9.0.org/doc/examples/cmake-multiple-shared-libraries/cmake/FindLTTngUST.cmake lttng-ust-2.9.0/doc/examples/cmake-multiple-shared-libraries/cmake/FindLTTngUST.cmake +--- lttng-ust-2.9.0.org/doc/examples/cmake-multiple-shared-libraries/cmake/FindLTTngUST.cmake 2016-11-29 02:46:24.000000000 +0100 ++++ lttng-ust-2.9.0/doc/examples/cmake-multiple-shared-libraries/cmake/FindLTTngUST.cmake 2017-10-30 17:01:42.321775178 +0100 +@@ -49,6 +49,8 @@ + # build is a possibility (Yocto). + find_path(LTTNGUST_INCLUDE_DIRS_GENERATED NAMES lttng/ust-config.h) + find_library(LTTNGUST_LIBRARIES NAMES lttng-ust) ++find_library(LTTNGUST_LIBRARIES_DEP NAMES lttng-ust-tracepoint) ++ + + if(LTTNGUST_INCLUDE_DIRS AND LTTNGUST_INCLUDE_DIRS_GENERATED AND LTTNGUST_LIBRARIES) + # find tracef() and tracelog() support +@@ -97,13 +99,14 @@ + add_library(LTTng::UST UNKNOWN IMPORTED) + set_target_properties(LTTng::UST PROPERTIES + INTERFACE_INCLUDE_DIRECTORIES "${LTTNGUST_INCLUDE_DIRS};${LTTNGUST_INCLUDE_DIRS_GENERATED}" +- INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS} ++ INTERFACE_LINK_LIBRARIES "${LTTNGUST_LIBRARIES_DEP};${CMAKE_DL_LIBS}" + IMPORTED_LINK_INTERFACE_LANGUAGES "C" + IMPORTED_LOCATION "${LTTNGUST_LIBRARIES}") + endif() + + # add libdl to required libraries +- set(LTTNGUST_LIBRARIES ${LTTNGUST_LIBRARIES} ${CMAKE_DL_LIBS}) ++ set(LTTNGUST_LIBRARIES ${LTTNGUST_LIBRARIES} ${LTTNGUST_LIBRARIES_DEP} ${CMAKE_DL_LIBS}) + endif() + + # handle the QUIETLY and REQUIRED arguments and set LTTNGUST_FOUND to
The build of doc/examples/cmake-multiple-shared-libraries does fail as a dependend library is missing. This issue is not specific to builroot and should ideally be fixed upstream (Issue: https://bugs.lttng.org/issues/1132) The fix is done without any indepth knowledge of the CMake mechanisms, but seems to work correctly Signed-off-by: Norbert Lange <norbert.lange@andritz.com> --- package/lttng-libust/0005_fix_build.patch | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 package/lttng-libust/0005_fix_build.patch