Re: kernel bpf test_progs - vm wrong libc version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux