I have a situation with mumble where the build is breaking on armel architecture. Upstream has identified that this bug is due to the mumble "link" plugin containing atomic memory operations. I would like to conditionally patch the source plugins/CMakeLists.txt file based on architecutre to not build that one plugin for armel.
CDBS apparently has a way of doing this [1] and I would like to find a solution for doing this with debhelper.
I suppose in a pinch I could build-depend on the 'patch' command and do something like this in debian/rules:
ifeq ($(DEB_HOST_ARCH),armel)
patch < debian/patches/armel/95-fix-build-armel.patch
endif
Greetings.
I have a situation with mumble where the build is breaking on armel architecture. Upstream has identified that this bug is due to the mumble "link" plugin containing atomic memory operations. I would like to conditionally patch the source plugins/CMakeLists.txt file based on architecutre to not build that one plugin for armel. CDBS apparently has a way of doing this [1] and I would like to find a solution for doing this
with debhelper. I've been searching and haven't found anything quite
fitting.
Hi,
atomic operations require linking against libatomic — always have.
Some architectures inline a few functions, which is how you get away
with omitting the library on amd64 most of the time, but this is
incorrect.
No architecture specific patch should be required here, adding
libatomic everywhere is fine, possibly via -Wl,--push-options,--as-needed,-latomic,--pop-options
(although as-needed is likely default anyway)
Simon
Looking at the manpage for dpkg-architecture, the variable I may want to conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.
On Thu, Jan 16, 2025 at 09:48:53AM -0500, Chris Knadle wrote:
Greetings.Can the patched code just look like:
I have a situation with mumble where the build is breaking on armel
architecture. Upstream has identified that this bug is due to the mumble
"link" plugin containing atomic memory operations. I would like to
conditionally patch the source plugins/CMakeLists.txt file based on
architecutre to not build that one plugin for armel. CDBS apparently has a >> way of doing this [1] and I would like to find a solution for doing this
with debhelper. I've been searching and haven't found anything quite
fitting.
#ifdef __ARMEL__
// Patched code
#else
// original code with atomic memory ops
#endif
Looking at the manpage for dpkg-architecture, the variable I may want to conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.
atomic operations require linking against libatomic — always have. Some architectures inline a few functions, which is how you get away with omitting the library on amd64 most of the time, but this is incorrect.
No architecture specific patch should be required here, adding libatomic everywhere is fine, possibly via
-Wl,--push-options,--as-needed,-latomic,--pop-options
(although as-needed is likely default anyway)
atomic operations require linking against libatomic — always have. Some architectures inline a few functions, which is how you get away with omitting
the library on amd64 most of the time, but this is incorrect.
No architecture specific patch should be required here, adding libatomic everywhere is fine, possibly via
-Wl,--push-options,--as-needed,-latomic,--pop-options
(although as-needed is likely default anyway)
I find this very interesting. I am fighting -latomic linking issues for quite a
while now and what you just said makes me think that I am in severe lack of understanding here. Can you elaborate?
My specific situation is:
src:vcmi FTBFS on armel unless I apply this patch:
https://sources.debian.org/src/vcmi/1.5.7%2Bdfsg-1/debian/patches/fix-armel-atomics.patch/
After more research together with vcmi upstream involvement I found out that linking vcmi against atomic is *only* required because it uses tbb::parallel_for from oneTBB: https://github.com/uxlfoundation/oneTBB/issues/1454
And then others have linked me to this GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
So I'm at a loss at deciding who is at fault and who should be fixing something. You say this should work out-of-the-box on amd64 mostly but everything I have come across handling std::atomic types builds fine on all architectures -- except armel. So which is the thing that gets things wrong here?
- armel?
- g++?
- cmake?
- oneTBB?
- vcmi?
atomic operations require linking against libatomic — always have. Some architectures inline a few functions, which is how you get away with omitting the library on amd64 most of the time, but this is incorrect.
No architecture specific patch should be required here, adding libatomic everywhere is fine, possibly via -Wl,--push-options,--as-needed,-latomic,--pop-options
(although as-needed is likely default anyway)
Simon
I'm assuming this also requires adding libatomic1 as a build dependency.
On Thu, Jan 16, 2025 at 01:54:05PM -0500, Chris Knadle wrote:
ITYM libgcc-14-dev, and it's in build-essential.atomic operations require linking against libatomic — always have. Some >>> architectures inline a few functions, which is how you get away withI'm assuming this also requires adding libatomic1 as a build dependency.
omitting the library on amd64 most of the time, but this is incorrect.
No architecture specific patch should be required here, adding libatomic >>> everywhere is fine, possibly via
-Wl,--push-options,--as-needed,-latomic,--pop-options
(although as-needed is likely default anyway)
Simon
Looking at the manpage for dpkg-architecture, the variable I may want to conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.
Hi Simon,
Quoting Simon Richter (2025-01-16 16:52:19)
atomic operations require linking against libatomic — always have..
Some
architectures inline a few functions, which is how you get away
with omitting
the library on amd64 most of the time, but this is incorrect.
No architecture specific patch should be required here, adding
libatomic everywhere is fine, possibly via -Wl,--push-options,--as-needed,-latomic,--pop-options
(although as-needed is likely default anyway)
I find this very interesting. I am fighting -latomic linking issues
for quite a while now and what you just said makes me think that I am
in severe lack of understanding here. Can you elaborate?
So I'm at a loss at deciding who is at fault and who should be fixing something. You say this should work out-of-the-box on amd64 mostly but everything I have come across handling std::atomic types builds fine on all architectures -- except armel. So which is the thing that gets things wrong here?
- armel?
- g++?
- cmake?
- oneTBB?
- vcmi?
Who should be patched? Relevant Debian bugs are #1089991 and #1088922
I'd very much welcome to be enlightened by you or anybody else on
this list.. :)
It's not that complex.¹ If you use an atomic, you should also be
linking with atomic (i.e. -latomic). This is similar to using
-pthreads if you are using multiple threads, or -lresolv if you use gethostbyname()
Some upstreams have gone through build system tests to assess whether
to build with libatomic or not. Adding -latomic is simpler. I wonder if
the build system configure stage test is overkill.
In my own packages, I check if libatomic exists, and if it does, I unconditionally link if I use any atomics. I also check if the linker
accepts --push-flags, if it does I generate a -Wl,--push-flags,--as-needed,-latomic,--pop-flags sequence, if not, the unconditional link will generate dpkg-shlibdeps warnings about unnecessary linking on amd64, but that's better than failing on other platforms.
Can you explain why this:
-Wl,--push-flags,--as-needed,-latomic,--pop-flags
is better than
-as-needed,-latomic
I thought --as-needed on its own is sufficicent to avoid dpkg-shlibdeps warnings
about unnecessary linking (because it only links the things that are needed), so
I don't understand the need for the psuh/pop sequence (I must admit that I never
knew that existed until your message recently).
A question about --as-needed as an upstream developer who wants to
care about more than just Debian or Linux. Am I correct in assuming
this will work on any system using GNU binutils? And it doesn't
matter whether you are using gcc, clang, etc. What about other OS's
such as *BSD, MacOS, etc.?
On Tue, Jan 21, 2025 at 10:31:29AM -0500, Theodore Ts'o wrote:
A question about --as-needed as an upstream developer who wants to
care about more than just Debian or Linux. Am I correct in assuming
this will work on any system using GNU binutils? And it doesn't
matter whether you are using gcc, clang, etc. What about other OS's
such as *BSD, MacOS, etc.?
I often consult Gnulib for lore on this kind of thing. https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/lib-ignore.m4 seems to have some useful hints, with comments for those not fluent in
m4.
This also seems to be a standalone file, so if your project is using
Autoconf but not Gnulib, then you should be able to copy it into your project's local macro directory, add gl_IGNORE_UNUSED_LIBRARIES to configure.ac, and add $(IGNORE_UNUSED_LIBRARIES_CFLAGS) etc. to whatever *_LDFLAGS variable is appropriate.
I guess I could add an autoconf test to see if the linker barfs on --as-needed, but I'm curious how much this actually matters in
practice.
In my own packages, I check if libatomic exists, and if it does, I unconditionally link if I use any atomics. I also check if the linker accepts --push-flags, if it does I generate a -Wl,--push-flags,--as-needed,-latomic,--pop-flags sequence, if not, the unconditional link will generate dpkg-shlibdeps warnings about unnecessary linking on amd64, but that's better than failing on other platforms.
I understand from the other mails that this architecture-check is not even needed and that --as-needed will let the linker do the right thing. I still like to special-case the only arch where this seems to be needed.
I gave up on
hoping that onetbb fixes it as neither upstream nor the Debian bug show any activity, so I'm patching my own package instead.
/usr/bin/ld: unrecognized option '--push-flags'
You probably meant --push-state and --pop-state instead?
Quoting Simon Richter (2025-01-17 11:43:39)
In my own packages, I check if libatomic exists, and if it does, I unconditionally link if I use any atomics. I also check if the linker accepts
--push-flags, if it does I generate a -Wl,--push-flags,--as-needed,-latomic,--pop-flags sequence, if not, the unconditional link will generate dpkg-shlibdeps warnings about unnecessary linking on amd64, but that's better than failing on other platforms.
thank you for your help! I now patched vcmi with snippets like this:
if (CMAKE_LIBRARY_ARCHITECTURE STREQUAL "arm-linux-gnueabi")
target_link_options(vcmi PRIVATE "-Wl,--push-flags,--as-needed,-latomic,--pop-flags")
endif()
I understand from the other mails that this architecture-check is not even needed and that --as-needed will let the linker do the right thing. I still like to special-case the only arch where this seems to be needed. I gave up on
hoping that onetbb fixes it as neither upstream nor the Debian bug show any activity, so I'm patching my own package instead.
But then I get the complaint:
/usr/bin/ld: unrecognized option '--push-flags'
You probably meant --push-state and --pop-state instead?
I suspect that the problem is the order in which the -latomic is added to the linker flags?
Because if instead of target_link_options() with push and
pop-state I just use
target_link_libraries(vcmiclient PRIVATE atomic)
Then that will add a -latomic right after ../bin/libvcmiclientcommon.a and then
the build succeeds.
So what is the canonical way to achieve the desired result with CMake? Will I instead have to globally set LDFLAGS="-Wl,--as-needed"?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 118:07:26 |
| Calls: | 9,687 |
| Calls today: | 3 |
| Files: | 13,728 |
| Messages: | 6,176,338 |