Bug #1344
closedlttng-modules v2.11 package fails to build with a custom Linux Kernel build using Buildroot
0%
Description
Hello,
I am not able to successfully build the lttng-modules package with Buildroot v2021.05. I get the following syntax errors:
output/build/lttng-modules-2.11.0/./probes/../instrumentation/events/lttng-module/timer.h:313:41: error: invalid use of undefined type ‘const struct itimerval’
313 | ctf_integer(long, interval_usec, value->it_interval.tv_usec)
| ^~
output/build/lttng-modules-2.11.0/./lib/../lib/ringbuffer/frontend.h:82:6: error: implicit declaration of function ‘smp_read_barrier_depends’ [-Werror=implicit-function-declaration]
82 | smp_read_barrier_depends(); (cpu) < nr_cpu_ids; });)
| ^~~~~~~~~~~~~~~~~~~~~~
/output/build/lttng-modules-2.11.0/./lib/../wrapper/trace-clock.h:168:3: error: implicit declaration of function ‘read_barrier_depends’ [-Werror=implicit-function-declaration]
168 | read_barrier_depends(); /* load ltc before content */
| ^~~~~~~~~~~~~~~~~~
The errors look mostly syntactical and is replicated with a fresh clone of v2021.08, v2021.11, v2020.05, v2020.08 also. The lttng-tools and lttng-babeltrace packages build without issues but the moment lttng-modules is selected and built, it fails. Is this issue known already? Are there any solutions for it?
I am attaching two .config files here. The reason is that I suspected the external tool chain option to create the issue, because of which I tried using buildroot's own tool chain. Unfortunately I encountered the same error using both configurations.
Files
Updated by Sreedhar Mahadevan almost 3 years ago
Would like to update one development from my end. I cloned the lttng-modules package directly from its Github repository: https://github.com/lttng/lttng-modules
From this lttng-modules environment, I tried building lttng-modules v2.13.0 based on the instructions in its README.md file by referencing the custom linux version that I was using (v5.10.x corresponding to Buildroot v2021.05) and it built successfully. When I tried building lttng-modules v2.12.0 and v2.11.0 and I got the exact error which I encountered in the Buildroot environment (reported earlier in this bug report). I see that buildroot v2021.08 and 2021.11 all continue using lttng-modules v2.11.0 and all seem to have the same issue.
Is this possibly the reason for the issue? If yes, how do I solve it? I tried hacking into the buildroot/package/lttng-modules/lttng-modules.mk and lttng-modules.hash files but I still faced issues with the wrong sha256 hashes. Can you please help?
Updated by Jonathan Rajotte Julien almost 3 years ago
- Status changed from New to Feedback
- Priority changed from Critical to Normal
Hi,
lttng-modules must follow kernel changes hence you need to use at least the latest patch level release of a stable version if you want maximum compatibility in regards to supported kernels.
From a quick git history search I suppose that the patch that address this problem is:
ommit 21ed5ea7e16fcce1cf1169b8e953e6d02ad531c9 Author: Michael Jeanson <mjeanson@efficios.com> Date: Tue Aug 25 10:56:29 2020 -0400 fix: removal of [smp_]read_barrier_depends (v5.9) See upstream commits: commit 76ebbe78f7390aee075a7f3768af197ded1bdfbb Author: Will Deacon <will@kernel.org> Date: Tue Oct 24 11:22:47 2017 +0100 locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE() In preparation for the removal of lockless_dereference(), which is the same as READ_ONCE() on all architectures other than Alpha, add an implicit smp_read_barrier_depends() to READ_ONCE() so that it can be used to head dependency chains on all architectures. commit 76ebbe78f7390aee075a7f3768af197ded1bdfbb Author: Will Deacon <will.deacon@arm.com> Date: Tue Oct 24 11:22:47 2017 +0100 locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE() In preparation for the removal of lockless_dereference(), which is the same as READ_ONCE() on all architectures other than Alpha, add an implicit smp_read_barrier_depends() to READ_ONCE() so that it can be used to head dependency chains on all architectures. Change-Id: Ife8880bd9378dca2972da8838f40fc35ccdfaaac Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Note that this patch is available (for the stable 2.11 branch) in:
joraj@~/lttng/master/lttng-modules [(45fe4e1a...)][]$ git tag --contains 21ed5ea7e16fcce1cf1169b8e953e6d02ad531c9 v2.11.6 v2.11.7 v2.11.8 v2.11.9
On 2.12.x it is available since:
joraj@~/lttng/stable-2.12/lttng-modules [master][]$ git tag --contains 57ccbfa6a8a79c7b84394c2097efaf7935607aa5 v2.12.3 v2.12.4 v2.12.5 v2.12.6 v2.12.7
Please upgrade lttng-modules to the latest available patch level release for the stable branch off your desire.
I'm no buildroot expert but it should be quite straight forward to change lttng-modules.mk and lttng-modules.hash
lttng-modules.mk:
LTTNG_MODULES_VERSION = 2.11.9
lttng-modules.hash
0c5fe9f8d8dbd1411a3c1c643dcbd0a55577bd15845758b73948e00bc7c387a6 lttng-modules-2.11.9.tar.bz2
Based on this update commit: https://github.com/buildroot/buildroot/commit/67ffe1f2a55140c1171b1afd596fb7b86595c82b to 2.11.0.
If this does not work, I suppose that reaching out to the package maintainers of the lttng-modules builroot package would be the next step to get some guidance.
Cheers
Updated by Sreedhar Mahadevan almost 3 years ago
Thanks a lot for the response. I shall try it out and give a feedback.
Updated by Sreedhar Mahadevan almost 3 years ago
Thanks once again. I was able to use lttng-modules with the changes to 2.11.9 in the .mk and .hash files.
Thanks a lot for the timely support.
Updated by Jonathan Rajotte Julien almost 3 years ago
- Status changed from Feedback to Resolved