On Tue, Jun 15, 2021 at 9:42 AM Geyslan G. Bem <geyslan@xxxxxxxxx> wrote: > > 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. > KP, how do you feel about teaching vmtest.sh to (optionally, if requested or if we detect that environment clang is too old) checkout clang and build it before building selftests? So many people would be grateful for this, I imagine! ;) > > > > [incase we decide to use the static linking for vmtest.sh] > > It's still a good decision for environments with readily available > static binaries. yeah, it's a good option to have at the very least > > Thanks a million for your attention. > > -- > Regards, > > Geyslan G. Bem
