* [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