Could we support lazy loading libbpf shared object file.

[Songrui625]

Hello, we make libbpfgo as a submodule of our project and use dynamic-build to build project. However, we encounter a problem that the binary file need to load libbpf shared file immediately once it being executed. The binary file will crash because the symbol of libc shared object file used by libbpf shared object file is not match with the version of libc shared object file on target machine.
I will appreciate If we could have a way to lazy loading libbpf shared object file.

[rafaeldtinoco]

Not sure I follow your request @Songrui625.

You can compile your project using libbpfgo + libbpf in a static way, then you won't depend on any shared object being lazy loaded.

The libbpfgo selftests, for example, can be compiled either using dynamic libbpf (from the OS shared library) or using static libbpf (using the ./libbpf internal directory). You can check that in their Makefiles.

Unless I didn't follow what you meant, then feel free to extend your thoughts.

[Songrui625]

Thanks for reply! @rafaeldtinoco

We used libbpfgo + libbpf in a static way earlier. It throw a warning:

/usr/bin/ld: /tmp/go-link-403921043/000004.o: in function `_cgo_e9f1c245e154_Cfunc_dlopen'
dl.cgo2.c:(.text+0x14c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

and we encounter some crash problems because we use dlopen to open other shared object file in our code.

Then we change to the dynamic way. When building libbpf.so, it will linked to the glibc shared object file. The version of glibc is 2.24( grater than 2.17) In our compiled machine, When runing the project in some machine, like CentOS 7 that the glibc version is 2.17, it will crash because of some symbol not found.

So we want to find a way that if a libbpfgo code is not able to run, we could free our project from libbpfgo. 🙏

[rafaeldtinoco]

We have the same issues in Tracee, for example. We provide different binaries for different distros in that case. So, for example, in that project, we "package" de application according to their GLIBC version (but still use static libbpf library).

Packaging code at: https://github.com/aquasecurity/tracee/tree/main/packaging

This way we can have multiple builds of the same version of our tool. Wouldn't that be possible for your tool ?

The reason why I say that is because libbpf is constantly changing and relying on the version available for the running distribution is a bad idea. It is better to keep the link in between:

• application version
• libbpfgo version
• libbpf version

Always the same.

Other way of solving the issue is to provide a "docker container image" of your application (where userland has always the same libs).

But, like you said, unfortunately having a static binary won't allow you to dlopen some other shared library you may have.

Maybe the best to do would be to package your application to each distro, but then instead of doing static libbpf compilation, to provide the libbpf shared object together with your binaries and always load the .so from a specific location (that would allow you to dlopen other shared libraries).

But I'm afraid no changes in libbfpo are needed for that to be made, no ? Libbpfgo already supports using a dynamic libbpf shared object, it would be just a question of preloading it from another location.

[Songrui625]

Thanks for your advice! @rafaeldtinoco
We package the application and load the libbpf shared library using LD_LIBRARY_PATH as you mentioned above.