On Tue, 15 Jun 2021 at 12:58, KP Singh <kpsingh@xxxxxxxxxx> wrote: > > On Tue, Jun 15, 2021 at 4:57 PM Geyslan G. Bem <geyslan@xxxxxxxxx> wrote: > > > > On Tue, 15 Jun 2021 at 11:33, KP Singh <kpsingh@xxxxxxxxxx> wrote: > > > > > > On Tue, Jun 15, 2021 at 2:34 PM Geyslan G. Bem <geyslan@xxxxxxxxx> wrote: > > > > > > > > On Tue, 15 Jun 2021 at 06:58, KP Singh <kpsingh@xxxxxxxxxx> wrote: > > > > > > > > > > On Tue, Jun 15, 2021 at 10:06 AM Jussi Maki <joamaki@xxxxxxxxx> wrote: > > > > > > > > > > > > On Tue, Jun 15, 2021 at 8:28 AM Andrii Nakryiko > > > > > > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > It seems kind of silly to update our perfectly working image just > > > > > > > because a new version of glibc was released. Is there any way for you > > > > > > > to down-grade glibc or build it in some compatibility mode, etc? > > > > > > > selftests don't really rely on any bleeding-edge features of glibc. > > > > > > > > > > > > I've also hit this issue as Ubuntu 21.04 ships with glibc 2.33. I > > > > > > ended up solving it the hard way by rebuilding the image (I needed few > > > > > > other tools at the time anyway). Definitely agree it's a bit silly if > > > > > > we'd need to bump the image every time there's a new glibc version out > > > > > > there. I did try and see if there's a way to build against newer > > > > > > glibc, but target older versions and I didn't find a way to do that. > > > > > > Would statically linking test-progs be an option to avoid this kind of > > > > > > breakage in the future? > > > > > > > > > > I think static linking tests_progs is the only real way one can solve this. > > > > > Even if we keep updating the image, there will still be users that will hit > > > > > glibc version issues. > > > > > > > > I agree once the image remains static. > > > > > > > > > > > > > > Andrii, Maybe we can have a mode for vmtest.sh can build test_progs > > > > > statically? > > > > > > > > > > maybe something like: > > > > > > > > These changes generates the output: > > > > > > > > BINARY test_maps > > > > /usr/bin/ld: cannot find -lcap > > > > collect2: error: ld returned 1 exit status > > > > make: *** [Makefile:492: > > > > /home/uzu/code/bpf-next/tools/testing/selftests/bpf/test_maps] Error 1 > > > > > > > > libcap and acl are installed > > > > > > Are you sure you have libcap-dev installed? I don't see this on my system. > > > > As Arch packages maintain headers, I suppose libcap has everything. > > > > $ yay -F libcap.so > > core/libcap 2.49-1 [installed: 2.50-2] > > usr/lib/libcap.so > > multilib/lib32-libcap 2.49-1 [installed: 2.50-1] > > usr/lib32/libcap.so > > > > $ yay -F cap-ng.h > > core/libcap-ng 0.8.2-1 [installed] > > usr/include/cap-ng.h > > > > $ ls -l /usr/include/cap* > > -rw-r--r-- 1 root root 3402 dez 9 2020 /usr/include/cap-ng.h > > > > $ ls -l /usr/lib/libcap* > > lrwxrwxrwx 1 root root 18 dez 9 2020 /usr/lib/libcap-ng.so -> > > libcap-ng.so.0.0.0 > > lrwxrwxrwx 1 root root 18 dez 9 2020 /usr/lib/libcap-ng.so.0 -> > > libcap-ng.so.0.0.0 > > -rwxr-xr-x 1 root root 26424 dez 9 2020 /usr/lib/libcap-ng.so.0.0.0 > > lrwxrwxrwx 1 root root 11 jun 7 14:25 /usr/lib/libcap.so -> libcap.so.2 > > lrwxrwxrwx 1 root root 14 jun 7 14:25 /usr/lib/libcap.so.2 -> libcap.so.2.50 > > -rw-r--r-- 1 root root 38704 jun 7 14:25 /usr/lib/libcap.so.2.50 > > > > https://archlinux.org/packages/core/x86_64/libcap/ > > https://archlinux.org/packages/core/x86_64/libcap-ng/ > > > > Anything, please contact me. I want to help. > > Apologies I missed adding the list in my previous reply. > > I think your distribution is missing static libcap > > $ dpkg -L libcap-dev > > [...] > > /usr/lib/x86_64-linux-gnu > /usr/lib/x86_64-linux-gnu/libcap.a > /usr/lib/x86_64-linux-gnu/libpsx.a > > [...] > > It seems like arch does not have them: > > https://bbs.archlinux.org/viewtopic.php?id=245303 Indeed. > > and they don't plan to either. So you can either build the library locally > or possibly move to a distribution that provides static linking. I think this would keep things in different host environments complicated. I'm more likely to create a proper VM to handle kernel source and bpf tests, since bpf also demands llvm13 (cutting edge) which is conflicting with other projects. > > [incase we decide to use the static linking for vmtest.sh] It's still a good decision for environments with readily available static binaries. Thanks a million for your attention. -- Regards, Geyslan G. Bem
