public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH bpf-next] bpftool: fix linkage with statically built libllvm
@ 2022-12-21 10:30 Anton Protopopov
  2022-12-21 19:33 ` sdf
  0 siblings, 1 reply; 3+ messages in thread
From: Anton Protopopov @ 2022-12-21 10:30 UTC (permalink / raw)
  To: bpf, Quentin Monnet; +Cc: Anton Protopopov, Jean-Philippe Brucker

Since the eb9d1acf634b commit ("bpftool: Add LLVM as default library for
disassembling JIT-ed programs") we might link the bpftool program with the
libllvm library.  This works fine when a dynamically built libllvm available,
but fails if we want to link bpftool with a statically built llvm:

    /usr/bin/ld: /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function `llvm::CrashRecoveryContextCleanup::~CrashRecoveryContextCleanup()':
    CrashRecoveryContext.cpp:(.text._ZN4llvm27CrashRecoveryContextCleanupD0Ev+0x17): undefined reference to `operator delete(void*, unsigned long)'
    /usr/bin/ld: /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function `llvm::CrashRecoveryContext::~CrashRecoveryContext()':
    CrashRecoveryContext.cpp:(.text._ZN4llvm20CrashRecoveryContextD2Ev+0xc8): undefined reference to `operator delete(void*, unsigned long)'
    ...

To fix this we need to explicitly link bpftool with required libraries, namely,
libstdc++ and those provided by `llvm-config --system-libs`.  This patch
doesn't change the build with a dynamically built libllvm, as the `llvm-config
--system-libs` list is empty in this case, and the bpftool is linked with the
libstdc++ in any case as this is a dynamic dependency of libLLVM.so.

eb9d1acf634b commit ("bpftool: Add LLVM as default library for disassembling JIT-ed programs")
Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
---
 tools/bpf/bpftool/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 787b857d3fb5..e4c15095eac7 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -144,7 +144,7 @@ ifeq ($(feature-llvm),1)
   CFLAGS  += -DHAVE_LLVM_SUPPORT
   LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
   CFLAGS  += $(shell $(LLVM_CONFIG) --cflags --libs $(LLVM_CONFIG_LIB_COMPONENTS))
-  LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
+  LIBS    += $(shell $(LLVM_CONFIG) --libs --system-libs $(LLVM_CONFIG_LIB_COMPONENTS)) -lstdc++
   LDFLAGS += $(shell $(LLVM_CONFIG) --ldflags)
 else
   # Fall back on libbfd
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH bpf-next] bpftool: fix linkage with statically built libllvm
  2022-12-21 10:30 [PATCH bpf-next] bpftool: fix linkage with statically built libllvm Anton Protopopov
@ 2022-12-21 19:33 ` sdf
  2022-12-22 10:20   ` Anton Protopopov
  0 siblings, 1 reply; 3+ messages in thread
From: sdf @ 2022-12-21 19:33 UTC (permalink / raw)
  To: Anton Protopopov; +Cc: bpf, Quentin Monnet, Jean-Philippe Brucker

On 12/21, Anton Protopopov wrote:
> Since the eb9d1acf634b commit ("bpftool: Add LLVM as default library for
> disassembling JIT-ed programs") we might link the bpftool program with the
> libllvm library.  This works fine when a dynamically built libllvm  
> available,
> but fails if we want to link bpftool with a statically built llvm:

>      /usr/bin/ld:  
> /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function  
> `llvm::CrashRecoveryContextCleanup::~CrashRecoveryContextCleanup()':
>       
> CrashRecoveryContext.cpp:(.text._ZN4llvm27CrashRecoveryContextCleanupD0Ev+0x17):  
> undefined reference to `operator delete(void*, unsigned long)'
>      /usr/bin/ld:  
> /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function  
> `llvm::CrashRecoveryContext::~CrashRecoveryContext()':
>       
> CrashRecoveryContext.cpp:(.text._ZN4llvm20CrashRecoveryContextD2Ev+0xc8):  
> undefined reference to `operator delete(void*, unsigned long)'
>      ...

> To fix this we need to explicitly link bpftool with required libraries,  
> namely,
> libstdc++ and those provided by `llvm-config --system-libs`.  This patch
> doesn't change the build with a dynamically built libllvm, as the  
> `llvm-config
> --system-libs` list is empty in this case, and the bpftool is linked with  
> the
> libstdc++ in any case as this is a dynamic dependency of libLLVM.so.

> eb9d1acf634b commit ("bpftool: Add LLVM as default library for  
> disassembling JIT-ed programs")
> Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
> ---
>   tools/bpf/bpftool/Makefile | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 787b857d3fb5..e4c15095eac7 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -144,7 +144,7 @@ ifeq ($(feature-llvm),1)
>     CFLAGS  += -DHAVE_LLVM_SUPPORT
>     LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
>     CFLAGS  += $(shell $(LLVM_CONFIG) --cflags --libs  
> $(LLVM_CONFIG_LIB_COMPONENTS))
> -  LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
> +  LIBS    += $(shell $(LLVM_CONFIG) --libs --system-libs  
> $(LLVM_CONFIG_LIB_COMPONENTS)) -lstdc++


Why not do separate lines? We can then maybe do a bit safer approach?

LIBS += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
ifeq ($(USE_STATIC_COMPONENTS), static)
LIBS += $(shell $(LLVM_CONFIG) --system-libs))
LIBS += -lstdc++
endif

Can we use `llvm-config --shared-mode` to get USE_STATIC_COMPONENTS?

>     LDFLAGS += $(shell $(LLVM_CONFIG) --ldflags)
>   else
>     # Fall back on libbfd
> --
> 2.34.1


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH bpf-next] bpftool: fix linkage with statically built libllvm
  2022-12-21 19:33 ` sdf
@ 2022-12-22 10:20   ` Anton Protopopov
  0 siblings, 0 replies; 3+ messages in thread
From: Anton Protopopov @ 2022-12-22 10:20 UTC (permalink / raw)
  To: sdf; +Cc: bpf, Quentin Monnet, Jean-Philippe Brucker

On 22/12/21 11:33, sdf@google.com wrote:
> On 12/21, Anton Protopopov wrote:
> >   [...]
> 
> > diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> > index 787b857d3fb5..e4c15095eac7 100644
> > --- a/tools/bpf/bpftool/Makefile
> > +++ b/tools/bpf/bpftool/Makefile
> > @@ -144,7 +144,7 @@ ifeq ($(feature-llvm),1)
> >     CFLAGS  += -DHAVE_LLVM_SUPPORT
> >     LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
> >     CFLAGS  += $(shell $(LLVM_CONFIG) --cflags --libs
> > $(LLVM_CONFIG_LIB_COMPONENTS))
> > -  LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
> > +  LIBS    += $(shell $(LLVM_CONFIG) --libs --system-libs
> > $(LLVM_CONFIG_LIB_COMPONENTS)) -lstdc++
> 
> 
> Why not do separate lines? We can then maybe do a bit safer approach?
> 
> LIBS += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
> ifeq ($(USE_STATIC_COMPONENTS), static)
> LIBS += $(shell $(LLVM_CONFIG) --system-libs))
> LIBS += -lstdc++
> endif
> 
> Can we use `llvm-config --shared-mode` to get USE_STATIC_COMPONENTS?

Thanks, I didn't know about the --shared-mode thing. I will send the v2.

> 
> >     LDFLAGS += $(shell $(LLVM_CONFIG) --ldflags)
> >   else
> >     # Fall back on libbfd
> > --
> > 2.34.1
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-12-22 10:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-21 10:30 [PATCH bpf-next] bpftool: fix linkage with statically built libllvm Anton Protopopov
2022-12-21 19:33 ` sdf
2022-12-22 10:20   ` Anton Protopopov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox