Add unresolved externs for rpi 32 build

[ntc490]

Got btop building on my RPi 3B+ running Raspian Lite 32.

[imwints]

Just out of curiosity, are you using the latest version of raspbian? And, are you building with or without GPU support?

[ntc490]

Good to hear from you. Sorry I just kinda threw that over the wall at you. You never know how people will respond and I didn't want to spend time unless it would help. I am using the latest version of Raspian. Just downloaded and installed a fresh version yesterday. I was building with BTOP_GPU on as it's the default. TBH I didn't look too closely at the options at first. I took a closer look and made a better change. It's pushed to my branch and should show up in the PR I think. LMK if you have any other questions or how I can help.  One other thought - might be nice to relax the CMake requirements if possible. I had to install CMake from source on my little RPi3B+, which takes forever. Raspian is on the old side with a lot of stuff: CMake is version 3.18. I tend to use a cmake_minimum_required of 3.14. BTW, thanks for btop! I love it and recommend it to all my coworkers. The only othe thing that compares is gtop, but that's a node+js app, which I don't like to deal with on a small system. Regards,Nathan On Sunday, January 7, 2024 at 10:49:34 AM MST, Steffen ***@***.***> wrote: Just out of curiosity, are you using the latest version of raspbian? If so, are you buildinh with or without GPU support? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[imwints]

The big thanks should go to @aristocratos, not myself.

The actual minimum version should be 3.25 because of the LINUX and APPLE variables introduced a couple of weeks ago

Regarding the requirement of libdl:
Since glibc-2.34 linking with -dl is not explicitly required anymore

In order to support smoother in-place-upgrades and to simplify
the implementation of the runtime all functionality formerly
implemented in the libraries libpthread, libdl, libutil, libanl has
been integrated into libc. New applications do not need to link with
-lpthread, -ldl, -lutil, -lanl anymore. [...]

You probably need to do some updates. From my RaspberryPi 4:

$ cat /etc/os-release | head -1 && dpkg -s libc-bin | grep Version && cmake --version | head -1

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" # Raspian
Version: 2.36-9+rpt2+deb12u3 # glibc
cmake version 3.25.1 # CMake

Also, you most likely should not use a 32-bit version of any distribution nowadays if your CPU supports 64-bit, which the Pi3 does.

[ntc490]

I was shocked I even had CMake 3.18 on my RPi from the repo. Debian tends to lag behind bleeding edge quite far. I've been using WIN32 and APPLE macros forever in CMake. For LINUX, I typically switch on 'if (UNIX AND NOT APPLE)'. Nice they finally added LINUX in CMake 3.25. I think APPLE and UNIX date back to version 3.02 or something ancient like that. Never had to look it up. I like this resource for versions: What's new in CMake · Modern CMake | | | | What's new in CMake · Modern CMake Henry Schreiner | | | There are still a lot of LTS distros that don't include CMake 3.25+. Might be nice to support something a tick older even if it means some pain for the CMake maintainer. Totally up to you of course. It's just one of the love-hate things about CMake. Glad it gets so many updates most days. There are a bunch of things like the -dl issue with different versions of libc. There are some differences between gcc and clang of the same era, too. I've had to code around issues like this in CMake a lot. I'm betting enough people want to use btop you'll have people trying to build with a toolchain that needs this tweak. Most of the systems I have to use at work are older on the libc and CMake front. My RPi is current - there are no more updates. TBH I ran a 32b OS because my system doesn't have more than 4G of RAM and 32b might be a touch quicker and definitely more compact. These things are so slow. It looked like RPi Imager was putting it high on the list, too. But... I didn't realize 32b is Bullseye vs Bookwork on 64b... point taken. The system will likely be more secure with a more modern distro. ➜  ~ cat /etc/os-release | head -1 && dpkg -s libc-bin | grep Version && cmake --version | head -1 && sudo apt update 2>&1 | tail -1PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"Version: 2.31-13+rpt2+rpi1+deb11u7cmake version 3.28.1  <== installed from sourceAll packages are up to date. Cheers,Nathan On Monday, January 8, 2024 at 03:21:15 AM MST, Steffen ***@***.***> wrote: The big thanks should go to @aristocratos, not myself. The actual minimum version should be 3.25 because of the LINUX and APPLE variables introduced a couple of weeks ago Regarding the requirement of libdl: Since glibc-2.34 linking with -dl is not explicitly required anymore In order to support smoother in-place-upgrades and to simplify the implementation of the runtime all functionality formerly implemented in the libraries libpthread, libdl, libutil, libanl has been integrated into libc. New applications do not need to link with -lpthread, -ldl, -lutil, -lanl anymore. [...] You probably need to do some updates. From my RaspberryPi 4: $ cat /etc/os-release | head -1 && dpkg -s libc-bin | grep Version && cmake --version | head -1 PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" # Raspian Version: 2.36-9+rpt2+deb12u3 # glibc cmake version 3.25.1 # CMake Also, you most likely should not use a 32-bit version of any distribution nowadays if your CPU supports 64-bit, which the Pi3 does. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ntc490]

Fun! Looks like there's a by in the RPI Imager. When I filtered by RPi3 I wasn't getting the option to use Bookworm. Had to clear my filter to install Bookworm Lite.https://forums.raspberrypi.com/viewtopic.php?t=358721

…

-Nathan On Monday, January 8, 2024 at 10:15:09 AM MST, Nathan Crapo ***@***.***> wrote: I was shocked I even had CMake 3.18 on my RPi from the repo. Debian tends to lag behind bleeding edge quite far. I've been using WIN32 and APPLE macros forever in CMake. For LINUX, I typically switch on 'if (UNIX AND NOT APPLE)'. Nice they finally added LINUX in CMake 3.25. I think APPLE and UNIX date back to version 3.02 or something ancient like that. Never had to look it up. I like this resource for versions: What's new in CMake · Modern CMake | | | | What's new in CMake · Modern CMake Henry Schreiner | | | There are still a lot of LTS distros that don't include CMake 3.25+. Might be nice to support something a tick older even if it means some pain for the CMake maintainer. Totally up to you of course. It's just one of the love-hate things about CMake. Glad it gets so many updates most days. There are a bunch of things like the -dl issue with different versions of libc. There are some differences between gcc and clang of the same era, too. I've had to code around issues like this in CMake a lot. I'm betting enough people want to use btop you'll have people trying to build with a toolchain that needs this tweak. Most of the systems I have to use at work are older on the libc and CMake front. My RPi is current - there are no more updates. TBH I ran a 32b OS because my system doesn't have more than 4G of RAM and 32b might be a touch quicker and definitely more compact. These things are so slow. It looked like RPi Imager was putting it high on the list, too. But... I didn't realize 32b is Bullseye vs Bookwork on 64b... point taken. The system will likely be more secure with a more modern distro. ➜  ~ cat /etc/os-release | head -1 && dpkg -s libc-bin | grep Version && cmake --version | head -1 && sudo apt update 2>&1 | tail -1PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"Version: 2.31-13+rpt2+rpi1+deb11u7cmake version 3.28.1  <== installed from sourceAll packages are up to date. Cheers,Nathan On Monday, January 8, 2024 at 03:21:15 AM MST, Steffen ***@***.***> wrote: The big thanks should go to @aristocratos, not myself. The actual minimum version should be 3.25 because of the LINUX and APPLE variables introduced a couple of weeks ago Regarding the requirement of libdl: Since glibc-2.34 linking with -dl is not explicitly required anymore In order to support smoother in-place-upgrades and to simplify the implementation of the runtime all functionality formerly implemented in the libraries libpthread, libdl, libutil, libanl has been integrated into libc. New applications do not need to link with -lpthread, -ldl, -lutil, -lanl anymore. [...] You probably need to do some updates. From my RaspberryPi 4: $ cat /etc/os-release | head -1 && dpkg -s libc-bin | grep Version && cmake --version | head -1 PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" # Raspian Version: 2.36-9+rpt2+deb12u3 # glibc cmake version 3.25.1 # CMake Also, you most likely should not use a 32-bit version of any distribution nowadays if your CPU supports 64-bit, which the Pi3 does. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[imwints]

In the worst case there are still the static release binaries or Docker + alpine where you can build the static binary yourself.

Since the Makefile doesn't do it I wouldn't like to do this to support (compiling against) some ancient glibc.
Being written with C++-20 btop is dependent on recent compilers anyway so it wouldn't make much sense to support (compiling against) older libc's while requiring new compilers.