Skip to contentSkip to conversation

Fix build of lttng-libust

PATCH New Norbert Lange 5 participants 13 messages Oct 30, 2017 – Nov 6, 2017

lore
Share & tools
lore

Norbert Lange

author
#0 lore raw

PATCH 1/1 Fix build of lttng-libust

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 <[email protected]>
---
 package/lttng-libust/0005_fix_build.patch | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 package/lttng-libust/0005_fix_build.patch
package/lttng-libust/0005_fix_build.patch new file +28 -0
new file mode 100644
index 0000000000..96be80aaa6
@@ -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
Signature · 1 line
2.14.2
#1 lore raw

PATCH 1/1 Fix build of lttng-libust

Hello,

Quoted 9 lines · 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 <[email protected]>

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
author
#2 lore raw

PATCH 1/1 Fix build of lttng-libust

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
<[email protected]>:

Quoted 18 lines

Hello,

Quoted 9 lines · 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 <[email protected]>

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.

Quoted 7 lines

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>

#3 lore raw

PATCH 1/1 Fix build of lttng-libust

Quoted 26 lines · 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
<[email protected]>:

Quoted 17 lines

Hello,

Quoted 9 lines · 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 <[email protected]>

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

Signature · 6 lines
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
#4 lore raw

PATCH 1/1 Fix build of lttng-libust

Arnout, All,

On 2017-11-05 17:13 +0100, Arnout Vandecappelle spake thusly:

Quoted 23 lines · Norbert Lange
Quoted 22 lines

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
<[email protected]>:

Quoted 13 lines

Hello,

Quoted 9 lines · 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 <[email protected]>
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines

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 [email protected]: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.

Quoted 42 lines

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

Signature · 10 lines
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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#5 lore raw

PATCH 1/1 Fix build of lttng-libust

Quoted 45 lines · Yann E. MORIN

Arnout, All,

On 2017-11-05 17:13 +0100, Arnout Vandecappelle spake thusly:

Quoted 23 lines · Norbert Lange
Quoted 22 lines

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
<[email protected]>:

Quoted 13 lines

Hello,

Quoted 9 lines · 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 <[email protected]>
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines

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:

Quoted 8 lines

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

Quoted 54 lines

Regards,
Yann E. MORIN.

Quoted 38 lines

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
Quoted 4 lines

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

'------------------------------^-------^------------------^--------------------'

#6 lore raw

PATCH 1/1 Fix build of lttng-libust

Philippe, All,

On 2017-11-05 14:55 -0500, Philippe Proulx spake thusly:

Quoted 1 line · Yann E. MORIN

[--SNIP--]

Quoted 3 lines
Quoted 2 lines

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" <[email protected]>
configure.ac +13 -0
index ca1de874..adbd8f90 100644
@@ -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])
doc/Makefile.am +5 -1
index e110ed85..82689c5c 100644
@@ -1,3 +1,7 @@
-SUBDIRS = . man examples
+if EXAMPLES_OPT
+EXAMPLES_SUBDIRS = examples
+endif
+
+SUBDIRS = . man $(EXAMPLES_SUBDIRS)
 
 dist_doc_DATA = java-agent.txt
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#7 lore raw

PATCH 1/1 Fix build of lttng-libust

Philippe, All,

On 2017-11-05 22:10 +0100, Yann E. MORIN spake thusly:

Quoted 23 lines

On 2017-11-05 14:55 -0500, Philippe Proulx spake thusly:

Quoted 1 line · Yann E. MORIN

[--SNIP--]

Quoted 3 lines
Quoted 2 lines

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" <[email protected]>
configure.ac +2 -0
index ca1de874..adbd8f90 100644
@@ -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(

configure.ac they will not be installed. · line 482

Quoted 10 lines
configure.ac +10 -0
+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=

configure.ac +13 -0
index ca1de874..adbd8f90 100644
@@ -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])
doc/Makefile.am +5 -1
index e110ed85..82689c5c 100644
@@ -1,3 +1,7 @@
-SUBDIRS = . man examples
+if EXAMPLES_OPT
+EXAMPLES_SUBDIRS = examples
+endif
+
+SUBDIRS = . man $(EXAMPLES_SUBDIRS)
 
 dist_doc_DATA = java-agent.txt
Quoted 29 lines
configure.ac +0 -0
 # Default values
 AC_DEFUN([_AC_DEFINE_AND_SUBST], [
 	AC_DEFINE_UNQUOTED([CONFIG_$1], [$2], [$1])
doc/Makefile.am +5 -1
index e110ed85..82689c5c 100644
@@ -1,3 +1,7 @@
-SUBDIRS = . man examples
+if EXAMPLES_OPT
+EXAMPLES_SUBDIRS = examples
+endif
+
+SUBDIRS = . man $(EXAMPLES_SUBDIRS)
 
 dist_doc_DATA = java-agent.txt
Signature · 11 lines
-- 
.-----------------.--------------------.------------------.--------------------.
|  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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
author
#8 lore raw

PATCH 1/1 Fix build of lttng-libust

In reply to Arnout Vandecappelle

2017-11-05 17:13 GMT+01:00 Arnout Vandecappelle <[email protected]>:

Quoted 25 lines · Norbert Lange
Quoted 22 lines

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
<[email protected]>:

Quoted 13 lines

Hello,

Quoted 9 lines · 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 <[email protected]>
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines

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.

Quoted 18 lines

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.

Quoted 5 lines

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

Quoted 5 lines

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

Quoted 11 lines

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
#9 lore raw

PATCH 1/1 Fix build of lttng-libust

Quoted 31 lines · Norbert Lange

2017-11-05 17:13 GMT+01:00 Arnout Vandecappelle <[email protected]>:

Quoted 30 lines · Norbert Lange
Quoted 26 lines

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
<[email protected]>:

Quoted 17 lines

Hello,

Quoted 9 lines · 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 <[email protected]>

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 18 lines
Quoted 17 lines

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

Quoted 1 line

So I take, you can reproduce it.

Indeed, with the defconfig you sent before it can be reproduced.

Quoted 7 lines
Quoted 5 lines

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.

Quoted 5 lines
Quoted 3 lines

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.

Quoted 2 lines

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

Signature · 6 lines
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
#10 lore raw

PATCH 1/1 Fix build of lttng-libust

Quoted 10 lines · Arnout Vandecappelle
Quoted 7 lines
Quoted 5 lines

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

Quoted 16 lines
Quoted 2 lines

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
#11 lore raw

PATCH 1/1 Fix build of lttng-libust

Hello,

Quoted 5 lines · Philippe Proulx
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

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?

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#12 lore raw

PATCH 1/1 Fix build of lttng-libust

Quoted 19 lines · Thomas Petazzoni

Hello,

Quoted 5 lines · Philippe Proulx
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

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?

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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!

Quoted 7 lines

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

Quoted 8 lines

Thanks!

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