btop: [BUG] Build broken on Catalina and below: linking errors, unconditional usage of non-existing headers
Fails to build on Catalina and below: https://trac.macports.org/ticket/68871
On El Capitan down this fails (at least):
src/osx/sensors.cpp:22:10: fatal error: 'IOKit/hidsystem/IOHIDEventSystemClient.h' file not found
#include <IOKit/hidsystem/IOHIDEventSystemClient.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/osx/sensors.cpp:22:10: note: did not find header 'hidsystem/IOHIDEventSystemClient.h' in framework 'IOKit' (loaded from '/System/Library/Frameworks')
1 warning and 1 error generated.
make: *** [obj/osx/sensors.o] Error 1
On Catalina through Sierra linking fails:
Linking and optimizing binary...
undef: __ZNSt3__120__libcpp_atomic_waitEPVKvx
undef: __ZNSt3__123__libcpp_atomic_monitorEPVKv
undef: __ZNSt3__123__cxx_atomic_notify_oneEPVKv
Undefined symbols for architecture x86_64:
"std::__1::__libcpp_atomic_wait(void const volatile*, long long)", referenced from:
Runner::_runner(void*) in lto.o
"std::__1::__libcpp_atomic_monitor(void const volatile*)", referenced from:
Runner::_runner(void*) in lto.o
"std::__1::__cxx_atomic_notify_one(void const volatile*)", referenced from:
Runner::run(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, bool) in lto.o
Runner::stop() in lto.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [btop] Error 1
I will test on PowerPC tomorrow, but expect the same headers errors at the very least.
About this issue
- Original URL
- State: open
- Created 7 months ago
- Comments: 19 (8 by maintainers)
For the El Capitan issue,
IOKit/hidsystem/IOHIDEventSystemClient.h
was not documented as far as I know. Also this code is only needed for Apple Silicon, so we can easily make this conditional on macOS versions above Big Sur only.Edit: see https://github.com/aristocratos/btop/pull/690
Well, having support for all but the first 5 versions should probably be good enough 😉
Ping me if you get stuck on anything and I’ll try to help when I’ve got time.
Good luck 👍
@barracuda156 Feel free to create a PR if you wanna work on adapting it for more backwards compatibility.
But I’m guessing there will be a wall at some point because of compiler compatibility (needs C++20 support).
And for the first issue, I’d be interested if the error is reproducible with cmake aswell, because in comparison to the make build cmake adds some macOS sdk paths by default
Edit: Ok the macports build also passes the sdk flags so this shouldn’t be an issue