[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Norbert Lange]

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

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

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Thomas Petazzoni]

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

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Norbert Lange]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lttng_failbuild_defconfig
Type: application/octet-stream
Size: 349 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171031/92381c6f/attachment.obj>

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Arnout Vandecappelle]

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 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] [PATCH 1/1] Fix build of lttng-libust

[Yann E. MORIN]

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@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 at 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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Philippe Proulx]

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 at 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.  |
> '------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Norbert Lange]

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

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Yann E. MORIN]

Philippe, All,

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"])
+
 # 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] [PATCH 1/1] Fix build of lttng-libust

[Yann E. MORIN]

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 at 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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Arnout Vandecappelle]

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

-- 
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] [PATCH 1/1] Fix build of lttng-libust

[Philippe Proulx]

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

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] Fix build of lttng-libust

[Philippe Proulx]

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