Description of problem: lttng-ust fails to build from source for Fedora EPEL7 on RHELSA-7.2. Version-Release number of selected component (if applicable): lttng-ust-2.4.1-1.el7 How reproducible: consistently Steps to Reproduce: 1. On a RHELSA-7.2 host: mock rebuild lttng-ust-2.4.1-1.el7.src.rpm 2. 3. Actual results: Fails to build with the following error: checking host system alignment requirements... configure: error: unable to detect alignment requirements (unsupported architecture (aarch64)?) error: Bad exit status from /var/tmp/rpm-tmp.bYymwb (%build) Bad exit status from /var/tmp/rpm-tmp.bYymwb (%build) Expected results: builds without errors. Additional info: Version lttng-ust-2.5.1-2.fc21.src.rpm builds successfully on AArch64 * Tue Dec 09 2014 Peter Robinson <pbrobinson> 2.5.1-2 - Add patch to fix aarch64 support Please backport the required changes or rebase to the later Fedora version.
Ken, Any plans to rebase or backport to fix this?
I've tested that 2.8.1-2 from Rawhide builds fine on aarch64. Ok to go with this version?
lttng-ust-2.8.1-2 builds fine for me, but when I try to use it to build lttng-tools-2.4.1 (to meet the dependency), I get the following error: ust-consumer.c: In function 'create_ust_channel': ust-consumer.c:363:2: error: too few arguments to function 'ustctl_create_channel' channel = ustctl_create_channel(attr); ^ In file included from ust-consumer.c:21:0: /usr/include/lttng/ust-ctl.h:165:2: note: declared here ustctl_create_channel(struct ustctl_consumer_channel_attr *attr, ^ make[3]: *** [ust-consumer.lo] Error 1 I also tried building the rawhide version of lttng-tools (2.8.0-1), but got the same error. I am building on RHELSA-7.2 for EPEL7 (not rawhide). Building against lttng-ust-2.5.1-2 works without issue.
If we have no better alternative, please go with 2.8.1-2, and we'll deal with lttng-tools in a separate BZ.
lttng-tools and lttng-ust have to be upgraded in lockstep, mixing major versions like 2.8 and 2.5 is untested and unsupported.
Ok, I'm open to suggestions. As mentioned above, both lttng-ust and lttng-tools 2.5.1-2 build for AArch64 EPEL, but lttng-tools fails to build for 2.8.1-2. I'm not sure how this affects other archs and lttng plans, but from my perspective we have two options: 1) rebase to 2.5.1-2 for now, and work with upstream to fix Arch64 builds on 2.8+, or 2) try to fix lttng-tools-2.8.1-2 to build on AArch64 now, and rebase (to the resulting version) when it works. Opinions and suggestions are appreciated.
The 2.8 rawhide packages should build without problem on rhel7 aarch64, we support this architecture on other distributions. I'll see if I can do a test build on copr / koji.
I just completed a local build of lttng-tools-2.8.1-1.fc26 against lttng-ust-2.8.1-2.el7, and it built successfully. If we can rebase to those I think we are in good shape for AArch64 EPEL7 builds.
Is this going to be a seamless upgrade for users who have built against lttng 2.4.1 that's currently in EPEL 7? Is the ABI compatible?
https://lists.centos.org/pipermail/centos-devel/2016-October/015214.html could be useful for checking the differences here
Michael: Do you know the answer to Ken's question? (Are lttng-ust-2.4.1 and lttng-ust-2.8.1 ABI compatible?) Since lttng-ust and lttng-tools must be kept in lockstep, it seems lttng might not be ABI compatible across major versions, in which case rebasing in EPEL7 could cause compatibility issues.
While this big of a version gap is not well tested, it is part of our design goals that an application dynamically linked with liblttng-ust should work with any later version of the library in the same major (2.x). The worst case scenario is that no tracing event will be generated but the execution of the app should never be impacted.
Is there anything we can do to move this forward? If the bump to lttng-ust-2.8.1 is considered to big of a risk, can we submit 2.5.1-2 (one minor version newer), which is already built for AArch64 in Fedora, as an EPEL7 update? Another alternative is to backport the (one line) patch in 2.5.1-2 to the current release. I have submitted EPEL7 scratch builds for both alternatives: 2.4.1 - http://koji.fedoraproject.org/koji/taskinfo?taskID=16240593 2.5.1 - http://koji.fedoraproject.org/koji/taskinfo?taskID=16240819 and both build without errors. Please let me know if there is anything else I can do to help resolve this.
dmarlin, I've granted you permissions in pkgdb to lttng-ust and lttng-tools for master (Rawhide) and epel7. Please feel free to push and build to resolve this.
lttng-ust-2.4.1-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-68f289e90b
lttng-ust-2.4.1-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.