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
$ ld --version
GNU ld (GNU Binutils) 2.36.1
$ ld.lld --version
LLD 13.0.0 (/home/uzu/.cache/yay/llvm-git/llvm-project
ad381e39a52604ba07e1e027e7bdec1c287d9089) (compatible with GNU
linkers)
>
> git diff
> diff --git a/tools/testing/selftests/bpf/Makefile
> b/tools/testing/selftests/bpf/Makefile
> index f405b20c1e6c..5ab0b7e6a95d 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -450,7 +450,7 @@ $(OUTPUT)/$(TRUNNER_BINARY): $(TRUNNER_TEST_OBJS)
> \
> $(RESOLVE_BTFIDS) \
> | $(TRUNNER_BINARY)-extras
> $$(call msg,BINARY,,$$@)
> - $(Q)$$(CC) $$(CFLAGS) $$(filter %.a %.o,$$^) $$(LDLIBS) -o $$@
> + $(Q)$$(CC) $$(CFLAGS) $(TRUNNER_LDFLAGS) $$(filter %.a
> %.o,$$^) $$(LDLIBS) -o $$@
> $(Q)$(RESOLVE_BTFIDS) --no-fail --btf $(TRUNNER_OUTPUT)/btf_data.o $$@
>
> endef
> diff --git a/tools/testing/selftests/bpf/vmtest.sh
> b/tools/testing/selftests/bpf/vmtest.sh
> index 8889b3f55236..331072074014 100755
> --- a/tools/testing/selftests/bpf/vmtest.sh
> +++ b/tools/testing/selftests/bpf/vmtest.sh
> @@ -138,7 +138,7 @@ update_selftests()
> local selftests_dir="${kernel_checkout}/tools/testing/selftests/bpf"
>
> cd "${selftests_dir}"
> - ${make_command}
> + TRUNNER_LDFLAGS=-static ${make_command}
>
> # Mount the image and copy the selftests to the image.
> mount_image
>
> file test_progs
> test_progs: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
> statically linked,
> BuildID[sha1]=b1915565b344c412f3eaa07eef4bfdd4a0fc672e, for GNU/Linux
> 3.2.0, with debug_info, not stripped
>
> I tried with simply doing LDFLAGS=-static but that breaks other binaries:
Earlier I tried just that too. Same results.
>
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/crtbeginT.o: relocation
> R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when
> making a shared object
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:167:
> /home/kpsingh/projects/krsi/tools/testing/selftests/bpf/tools/build/libbpf/libbpf.so.0.5.0]
> Error 1
> make[1]: *** [Makefile:135: all] Error 2
> make: *** [Makefile:228:
> /home/kpsingh/projects/krsi/tools/testing/selftests/bpf/tools/build/libbpf/libbpf.a]
> Error 2
> make: *** Deleting file
> '/home/kpsingh/projects/krsi/tools/testing/selftests/bpf/tools/build/libbpf/libbpf.a'
>
> Let me know if this works for you.
>
>
>
>
> -
--
Regards,
Geyslan G. Bem
