Skip to contentSkip to conversation

Lttng packages bump

PATCH Superseded Samuel Martin 2 participants 12 messages Mar 1, 2014 – Mar 7, 2014

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

cover Lttng packages bump

Hi all,

Here is a short series bumping LTTng related packages to their latest version.

Yours,
Samuel

Samuel Martin (6):
liburcu: bump version to 0.8.3
lttng-libust: bump version to 2.4.0
lttng-modules: bump version to 2.4.0
lttng-tools: bump version to 2.4.0
lttng-babeltrace: bump version to 1.2.0
liburcu: disable build with gcc-4.8.x on ARM

 package/liburcu/Config.in                    | 11 +++++++++++
 package/liburcu/liburcu.mk                   |  6 +++---
 package/lttng-babeltrace/lttng-babeltrace.mk |  6 +++---
 package/lttng-libust/Config.in               |  6 ++++++
 package/lttng-libust/lttng-libust.mk         |  4 ++--
 package/lttng-modules/lttng-modules.mk       |  2 +-
 package/lttng-tools/Config.in                |  6 ++++++
 package/lttng-tools/lttng-tools.mk           |  7 +++----
 8 files changed, 35 insertions(+), 13 deletions(-)

--
1.9.0

#1 lore raw

PATCH 1/6 liburcu: bump version to 0.8.3

Also adjust the license details

---
 package/liburcu/liburcu.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
package/liburcu/liburcu.mk +3 -3
index a586382..44b640d 100644
@@ -4,11 +4,11 @@
 #
 ################################################################################
 
-LIBURCU_VERSION = 0.7.7
+LIBURCU_VERSION = 0.8.3
 LIBURCU_SITE    = http://lttng.org/files/urcu/
 LIBURCU_SOURCE  = userspace-rcu-$(LIBURCU_VERSION).tar.bz2
-LIBURCU_LICENSE = LGPLv2.1+ for the library; MIT-like license for few source files listed in LICENSE
-LIBURCU_LICENSE_FILES = lgpl-2.1.txt lgpl-relicensing.txt LICENSE
+LIBURCU_LICENSE = LGPLv2.1+ for the library; MIT-like license for few source files listed in LICENSE; GPLv2+ for test; GPLv3 for few *.m4 files
+LIBURCU_LICENSE_FILES = lgpl-2.1.txt lgpl-relicensing.txt gpl-2.0.txt LICENSE
 
 LIBURCU_INSTALL_STAGING = YES
 
Signature · 1 line
1.9.0
#2 lore raw

PATCH 2/6 lttng-libust: bump version to 2.4.0

In reply to Samuel Martin

Also adjust the license details

---
 package/lttng-libust/lttng-libust.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
package/lttng-libust/lttng-libust.mk +2 -2
index b0ebd3f..375a6a3 100644
@@ -5,9 +5,9 @@
 ################################################################################
 
 LTTNG_LIBUST_SITE    = http://lttng.org/files/lttng-ust/
-LTTNG_LIBUST_VERSION = 2.2.0
+LTTNG_LIBUST_VERSION = 2.4.0
 LTTNG_LIBUST_SOURCE  = lttng-ust-$(LTTNG_LIBUST_VERSION).tar.bz2
-LTTNG_LIBUST_LICENSE = LGPLv2.1; GPLv2 for lttng-gen-tp and ust-ctl
+LTTNG_LIBUST_LICENSE = LGPLv2.1; MIT for system headers; GPLv2 for liblttng-ust-ctl/ustctl.c (used by lttng-sessiond)
 LTTNG_LIBUST_LICENSE_FILES = COPYING
 
 LTTNG_LIBUST_INSTALL_STAGING = YES
Signature · 1 line
1.9.0
#3 lore raw

PATCH 3/6 lttng-modules: bump version to 2.4.0

In reply to Samuel Martin
---
 package/lttng-modules/lttng-modules.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/lttng-modules/lttng-modules.mk +1 -1
index baa421e..ca51e87 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-LTTNG_MODULES_VERSION = 2.2.0
+LTTNG_MODULES_VERSION = 2.4.0
 LTTNG_MODULES_SITE    = http://lttng.org/files/lttng-modules/
 LTTNG_MODULES_SOURCE  = lttng-modules-$(LTTNG_MODULES_VERSION).tar.bz2
 LTTNG_MODULES_LICENSE = LGPLv2.1/GPLv2 for kernel modules; MIT for lib/bitfield.h and lib/prio_heap/*
Signature · 1 line
1.9.0
#4 lore raw

PATCH 4/6 lttng-tools: bump version to 2.4.0

In reply to Samuel Martin

Also adjust the license details

---
 package/lttng-tools/lttng-tools.mk | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
package/lttng-tools/lttng-tools.mk +3 -4
index f6eff96..260bf82 100644
@@ -4,12 +4,11 @@
 #
 ################################################################################
 
-LTTNG_TOOLS_VERSION = 2.2.0
+LTTNG_TOOLS_VERSION = 2.4.0
 LTTNG_TOOLS_SITE    = http://lttng.org/files/lttng-tools/
 LTTNG_TOOLS_SOURCE  = lttng-tools-$(LTTNG_TOOLS_VERSION).tar.bz2
-LTTNG_TOOLS_LICENSE = GPLv2; LGPLv2.1 for include/lttng/* and src/lib/lttng-ctl/*
-# gpl-2.0.txt and lgpl-2.1.txt files are missing from the sources
-LTTNG_TOOLS_LICENSE_FILES = LICENSE
+LTTNG_TOOLS_LICENSE = GPLv2+; LGPLv2.1+ for include/lttng/* and src/lib/lttng-ctl/*
+LTTNG_TOOLS_LICENSE_FILES = gpl-2.0.txt lgpl-2.1.txt LICENSE
 
 # The host-lttng-babeltrace technically isn't a required build
 # dependency. However, having the babeltrace utilities built for the
Signature · 1 line
1.9.0
#5 lore raw

PATCH 5/6 lttng-babeltrace: bump version to 1.2.0

In reply to Samuel Martin

Also adjust the license details

---
 package/lttng-babeltrace/lttng-babeltrace.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
package/lttng-babeltrace/lttng-babeltrace.mk +3 -3
index 044dac0..f72abd7 100644
@@ -5,10 +5,10 @@
 ################################################################################
 
 LTTNG_BABELTRACE_SITE    = http://lttng.org/files/babeltrace/
-LTTNG_BABELTRACE_VERSION = 1.1.1
+LTTNG_BABELTRACE_VERSION = 1.2.0
 LTTNG_BABELTRACE_SOURCE  = babeltrace-$(LTTNG_BABELTRACE_VERSION).tar.bz2
-LTTNG_BABELTRACE_LICENSE = MIT; LGPLv2 for include/babeltrace/list.h; GPLv3+ for formats/ctf/metadata/ctf-parser.h
-LTTNG_BABELTRACE_LICENSE_FILES = mit-license.txt LICENSE
+LTTNG_BABELTRACE_LICENSE = MIT; LGPL2.1 for include/babeltrace/list.h; GPLv2+ for test code
+LTTNG_BABELTRACE_LICENSE_FILES = mit-license.txt glp-2.0.txt LICENSE
 
 LTTNG_BABELTRACE_DEPENDENCIES = popt util-linux libglib2
 
Signature · 1 line
1.9.0
#6 lore raw

PATCH 6/6 liburcu: disable build with gcc-4.8.x on ARM

In reply to Samuel Martin

Because of a gcc bug [1], liburcu checks for compiler version [2] and stops the build prematurely if gcc-4.8.[0-2] is detected for ARM.

So, this patch tries to reflect this toolchain dependency on liburcu and all its reverse dependency packages.

However, a limitation of this is when the user is using a custom toolchain; that's why the bug details have been added in the liburcu help message.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
[2] http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310

---
 package/liburcu/Config.in      | 11 +++++++++++
 package/lttng-libust/Config.in |  6 ++++++
 package/lttng-tools/Config.in  |  6 ++++++
 3 files changed, 23 insertions(+)
package/liburcu/Config.in +11 -0
index 15ad5bd..90e9199 100644
@@ -1,6 +1,12 @@
 config BR2_PACKAGE_LIBURCU
 	bool "liburcu"
 	depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+	# liburcu/gcc-4.8.x bug
+	depends on !((BR2_arm || BR2_armeb) && (BR2_GCC_VERSION_4_8_X || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_10 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09 || \
+		BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201311))
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	help
 	  Userspace implementation of the Read-Copy-Update (RCU)
@@ -8,6 +14,11 @@ config BR2_PACKAGE_LIBURCU
 	  the LTTng tracing infrastructure, but can be used for other
 	  purposes as well.
 
+	  On ARM, liburcu cannot be built using gcc 4.8.0, 4.8.1 or 4.8.2
+	  because of:
+	    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
+	    http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310
+
 	  http://lttng.org/urcu
 
 comment "liburcu needs a toolchain w/ threads"
package/lttng-libust/Config.in +6 -0
index 5e1a6d4..7ec5053 100644
@@ -1,5 +1,11 @@
 config BR2_PACKAGE_LTTNG_LIBUST
 	bool "lttng-libust"
+	# liburcu/gcc-4.8.x bug
+	depends on !((BR2_arm || BR2_armeb) && (BR2_GCC_VERSION_4_8_X || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_10 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09 || \
+		BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201311))
 	select BR2_PACKAGE_LIBURCU
 	select BR2_PACKAGE_UTIL_LINUX
 	select BR2_PACKAGE_UTIL_LINUX_LIBUUID
package/lttng-tools/Config.in +6 -0
index 1e9e0c3..0f31bee 100644
@@ -1,5 +1,11 @@
 config BR2_PACKAGE_LTTNG_TOOLS
 	bool "lttng-tools"
+	# liburcu/gcc-4.8.x bug
+	depends on !((BR2_arm || BR2_armeb) && (BR2_GCC_VERSION_4_8_X || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_10 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09 || \
+		BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201311))
 	select BR2_PACKAGE_LIBURCU
 	select BR2_PACKAGE_POPT
 	select BR2_PACKAGE_UTIL_LINUX
Signature · 1 line
1.9.0
#7 lore raw

PATCH 6/6 liburcu: disable build with gcc-4.8.x on ARM

Dear Samuel Martin,

package/liburcu/Config.in line 9

Quoted 6 lines · Samuel Martin
package/liburcu/Config.in +6 -0
+	# liburcu/gcc-4.8.x bug
+	depends on !((BR2_arm || BR2_armeb) && (BR2_GCC_VERSION_4_8_X || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_10 || \
+		BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09 || \
+		BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201311))

The exclusion of BR2_GCC_VERSION_4_8_X is wrong, because we have in Buildroot the patch fixing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 gcc bug.

But generally, I'm not really happy with this approach, as we would have to update these dependencies every time we bump/change the external toolchain Kconfig options... Unfortunately I don't have a better suggestion.

Maybe I would prefer something like:

config BR2_TOOLCHAIN_HAS_GCC_BUG_58854
bool

And then the toolchain impacted by the bug would select it. For example, are you sure the Linaro toolchains are affected by the problem? Most likely they have backported the change that is needed to fix this problem.

Best regards,

Thomas

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

PATCH 6/6 liburcu: disable build with gcc-4.8.x on ARM

Hi Thomas, all,

Quoted 11 lines · Thomas Petazzoni

Dear Samuel Martin,

package/liburcu/Config.in line 9

Quoted 6 lines · Samuel Martin
package/liburcu/Config.in +6 -0
+     # liburcu/gcc-4.8.x bug
+     depends on !((BR2_arm || BR2_armeb) && (BR2_GCC_VERSION_4_8_X || \
+             BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_11 || \
+             BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_10 || \
+             BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09 || \
+             BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201311))
Quoted 8 lines

The exclusion of BR2_GCC_VERSION_4_8_X is wrong, because we have in Buildroot the patch fixing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 gcc bug.

But generally, I'm not really happy with this approach, as we would have to update these dependencies every time we bump/change the external toolchain Kconfig options... Unfortunately I don't have a better suggestion.

I did this because of the patch in liburcu checking for the compiler version. I did not notice BR carries the patch fixing this bug.

Quoted 10 lines

Maybe I would prefer something like:

config BR2_TOOLCHAIN_HAS_GCC_BUG_58854
bool

And then the toolchain impacted by the bug would select it. For example, are you sure the Linaro toolchains are affected by the problem? Most likely they have backported the change that is needed to fix this problem.

Indeed, it sounds like a less restrictive way of handling this (even if it implies more testing ;-])

Regards,

Signature · 1 line
Samuel
#9 lore raw

PATCH 6/6 liburcu: disable build with gcc-4.8.x on ARM

Dear Samuel Martin,

Quoted 11 lines · Samuel Martin
Quoted 8 lines

The exclusion of BR2_GCC_VERSION_4_8_X is wrong, because we have in Buildroot the patch fixing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 gcc bug.

But generally, I'm not really happy with this approach, as we would have to update these dependencies every time we bump/change the external toolchain Kconfig options... Unfortunately I don't have a better suggestion.

I did this because of the patch in liburcu checking for the compiler version. I did not notice BR carries the patch fixing this bug.

So liburcu checks itself that the gcc version should be different than 4.8.0, 4.8.1 and 4.8.2 ? It doesn't take into account that the 4.8.2 might have been patched to fix the problem ? Can this test be disabled ?

Thomas

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

PATCH 6/6 liburcu: disable build with gcc-4.8.x on ARM

Quoted 13 lines · Thomas Petazzoni

Dear Samuel Martin,

Quoted 9 lines · Samuel Martin
Quoted 8 lines

The exclusion of BR2_GCC_VERSION_4_8_X is wrong, because we have in Buildroot the patch fixing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 gcc bug.

But generally, I'm not really happy with this approach, as we would have to update these dependencies every time we bump/change the external toolchain Kconfig options... Unfortunately I don't have a better suggestion.

Quoted 5 lines
Quoted 2 lines

I did this because of the patch in liburcu checking for the compiler version. I did not notice BR carries the patch fixing this bug.

So liburcu checks itself that the gcc version should be different than 4.8.0, 4.8.1 and 4.8.2 ?

Yes, it's done by this patch:
http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310

Quoted 2 lines

It doesn't take into account that the 4.8.2
might have been patched to fix the problem ?

Nope :-/

Quoted 1 line

Can this test be disabled ?

Certainly, I'm just not sure checking the compiler has the fix will be easy... anyway.

Just to be clear, your suggestion is only about enabling gcc-4.8.2 (with the fix), not gcc-4.8.0 nor gcc-4.8.1, right?
Then we have to check for each external toolchain if it has the fix.

What about custom toolchain based on gcc-4.8.2? Shall we able it (warning the user) or just disabling it?

Regards,

Signature · 1 line
Samuel
#11 lore raw

PATCH 6/6 liburcu: disable build with gcc-4.8.x on ARM

Dear Samuel Martin,

Quoted 5 lines · Samuel Martin
Quoted 2 lines

So liburcu checks itself that the gcc version should be different than 4.8.0, 4.8.1 and 4.8.2 ?

Yes, it's done by this patch:
http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310

This patch is a bit stupid. It should actually test for the problem itself, not make some assumption about the gcc version.

Quoted 2 lines

Just to be clear, your suggestion is only about enabling gcc-4.8.2 (with the fix), not gcc-4.8.0 nor gcc-4.8.1, right?

We don't support 4.8.0 and 4.8.1 in the internal toolchain backend.

Quoted 1 line

Then we have to check for each external toolchain if it has the fix.

Yes.

Quoted 2 lines

What about custom toolchain based on gcc-4.8.2? Shall we able it (warning the user) or just disabling it?

For custom toolchains, we have absolutely no idea which gcc version is being used at the Kconfig level, so I don't know how we could disallow building the package in this case.

That being said, the kernel also mis-compiles on ARM with gcc 4.8.x if you don't have this fix, and we haven't done anything to prevent people from building the kernel against unfixed versions of gcc 4.8.x. Therefore, should we care about liburcu ?

Thanks,

Thomas

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