[PATCH bpf] libbpf: add macro __BUILD_STATIC_LIBBPF__ to guard .symver

[PATCH bpf] libbpf: add macro __BUILD_STATIC_LIBBPF__ to guard .symver

[Yonghong Song]

bcc uses libbpf repo as a submodule. It brings in libbpf source
code and builds everything together to produce shared libraries.
With latest libbpf, I got the following errors:
  /bin/ld: libbcc_bpf.so.0.10.0: version node not found for symbol xsk_umem__create@LIBBPF_0.0.2
  /bin/ld: failed to set dynamic section sizes: Bad value
  collect2: error: ld returned 1 exit status
  make[2]: *** [src/cc/libbcc_bpf.so.0.10.0] Error 1

In xsk.c, we have
  asm(".symver xsk_umem__create_v0_0_2, xsk_umem__create@LIBBPF_0.0.2");
  asm(".symver xsk_umem__create_v0_0_4, xsk_umem__create@@LIBBPF_0.0.4");
The linker thinks the built is for LIBBPF but cannot find proper version
LIBBPF_0.0.2/4, so emit errors.

I also confirmed that using libbpf.a to produce a shared library also
has issues:
  -bash-4.4$ cat t.c
  extern void *xsk_umem__create;
  void * test() { return xsk_umem__create; }
  -bash-4.4$ gcc -c t.c
  -bash-4.4$ gcc -shared t.o libbpf.a -o t.so
  /bin/ld: t.so: version node not found for symbol xsk_umem__create@LIBBPF_0.0.2
  /bin/ld: failed to set dynamic section sizes: Bad value
  collect2: error: ld returned 1 exit status
  -bash-4.4$

To fix the problem, I simply added a macro __BUILD_STATIC_LIBBPF__
which will prevent issuing .symver assembly codes when enabled.
The .symver assembly codes are still issued by default.
This will at least give other libbpf users to build libbpf
without these versioned symbols.

I did not touch Makefile to actually use this macro to build
static library as I want to check whether this is desirable or not.

Signed-off-by: Yonghong Song <yhs@fb.com>
---
 tools/lib/bpf/xsk.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 24fa313524fb..76c12c4c5c70 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -261,8 +261,11 @@ int xsk_umem__create_v0_0_2(struct xsk_umem **umem_ptr, void *umem_area,
 	return xsk_umem__create_v0_0_4(umem_ptr, umem_area, size, fill, comp,
 					&config);
 }
+
+#ifndef __BUILD_STATIC_LIBBPF__
 asm(".symver xsk_umem__create_v0_0_2, xsk_umem__create@LIBBPF_0.0.2");
 asm(".symver xsk_umem__create_v0_0_4, xsk_umem__create@@LIBBPF_0.0.4");
+#endif
 
 static int xsk_load_xdp_prog(struct xsk_socket *xsk)
 {
-- 
2.17.1

Re: [PATCH bpf] libbpf: add macro __BUILD_STATIC_LIBBPF__ to guard .symver

[Daniel Borkmann]

On Thu, Sep 26, 2019 at 04:02:04PM -0700, Yonghong Song wrote:
> bcc uses libbpf repo as a submodule. It brings in libbpf source
> code and builds everything together to produce shared libraries.
> With latest libbpf, I got the following errors:
>   /bin/ld: libbcc_bpf.so.0.10.0: version node not found for symbol xsk_umem__create@LIBBPF_0.0.2
>   /bin/ld: failed to set dynamic section sizes: Bad value
>   collect2: error: ld returned 1 exit status
>   make[2]: *** [src/cc/libbcc_bpf.so.0.10.0] Error 1
> 
> In xsk.c, we have
>   asm(".symver xsk_umem__create_v0_0_2, xsk_umem__create@LIBBPF_0.0.2");
>   asm(".symver xsk_umem__create_v0_0_4, xsk_umem__create@@LIBBPF_0.0.4");
> The linker thinks the built is for LIBBPF but cannot find proper version
> LIBBPF_0.0.2/4, so emit errors.
> 
> I also confirmed that using libbpf.a to produce a shared library also
> has issues:
>   -bash-4.4$ cat t.c
>   extern void *xsk_umem__create;
>   void * test() { return xsk_umem__create; }
>   -bash-4.4$ gcc -c t.c
>   -bash-4.4$ gcc -shared t.o libbpf.a -o t.so
>   /bin/ld: t.so: version node not found for symbol xsk_umem__create@LIBBPF_0.0.2
>   /bin/ld: failed to set dynamic section sizes: Bad value
>   collect2: error: ld returned 1 exit status
>   -bash-4.4$
> 
> To fix the problem, I simply added a macro __BUILD_STATIC_LIBBPF__
> which will prevent issuing .symver assembly codes when enabled.
> The .symver assembly codes are still issued by default.
> This will at least give other libbpf users to build libbpf
> without these versioned symbols.
> 
> I did not touch Makefile to actually use this macro to build
> static library as I want to check whether this is desirable or not.

Isn't there any better way on how we can detect this? Asking users to
pass this macro to the build seems a suboptimal user experience. How
are other libraries solving this given this seems really not specific
to libbpf?

> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
>  tools/lib/bpf/xsk.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> index 24fa313524fb..76c12c4c5c70 100644
> --- a/tools/lib/bpf/xsk.c
> +++ b/tools/lib/bpf/xsk.c
> @@ -261,8 +261,11 @@ int xsk_umem__create_v0_0_2(struct xsk_umem **umem_ptr, void *umem_area,
>  	return xsk_umem__create_v0_0_4(umem_ptr, umem_area, size, fill, comp,
>  					&config);
>  }
> +
> +#ifndef __BUILD_STATIC_LIBBPF__
>  asm(".symver xsk_umem__create_v0_0_2, xsk_umem__create@LIBBPF_0.0.2");
>  asm(".symver xsk_umem__create_v0_0_4, xsk_umem__create@@LIBBPF_0.0.4");
> +#endif
>  
>  static int xsk_load_xdp_prog(struct xsk_socket *xsk)
>  {
> -- 
> 2.17.1
>