| Message ID | 20221221103007.1311799-1-aspsk@isovalent.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next] bpftool: fix linkage with statically built libllvm | expand |
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
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 >
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
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(-)