iovisor
Narrow libbcc dependency from llvm-dev to just libllvm
It works with list libllvm, so no need to pull in the whole thing, which is 600MiB worth of packages.
It works with list libllvm, so no need to pull in the whole thing, which is 600MiB worth of packages. @shunghsiyu, what exactly broke for you prior to #4921?
The problem for me is that using bcc header files (packaged as bcc-devel on RPM systems) requires llvm-devel to be on installed as well since 6f11bf7e2806658c4bd69415b921cedf85d9ebfe, otherwise compilation will fail. This is not a theoretical issue but an actual one that we saw with Sysinternals/ProcMon-for-Linux.
debian/control does not have a separate package to host the bcc header files so I ended up placing such requirement on the main bcc package, which is admittedly not ideal.
From a packaging point of view I'd much prefer we revert 6f11bf7e2806658c4bd69415b921cedf85d9ebfe to keep the dependency at a minimum.
That said I only know two users of bcc-devel: one is Sysinternals/ProcMon-for-Linux mentioned above, and the other is bpftrace/bpftrace. bpftrace already pulls llvm-devel itself anyway, while ProcMon-for-Linux doesn't get packaged everywhere; so this is perhaps a bit of bikeshedding.
@chantra what do you think?
On Sun, May 19, 2024 at 11:02 PM Shung-Hsi Yu @.***> wrote:
From a packaging point of view I'd much prefer we revert 6f11bf7 https://github.com/iovisor/bcc/commit/6f11bf7e2806658c4bd69415b921cedf85d9ebfe to keep the dependency at a minimum.
For packaging, this should only be a build dependency right: https://www.debian.org/doc/debian-policy/ch-relationships.html ? The package itself has a pretty minimal footprint (26kb on Ubuntu per https://packages.ubuntu.com/noble/llvm-dev). Probably this pulls more deps, but only on the build machine.
Quickly checking the issue, I think moving llvm-dev to a “Build-Depends” would solve the problem for machines where bcc gets installed.
Would that be a good enough middle ground?
That said I only know two users of bcc-devel: one is
Sysinternals/ProcMon-for-Linux https://github.com/Sysinternals/ProcMon-for-Linux mentioned above, and the other is bpftrace/bpftrace https://github.com/bpftrace/bpftrace. bpftrace already pulls llvm-devel anyway, while ProcMon-for-Linux doesn't get packaged everywhere; so this is perhaps a bit of bikeshedding.
@chantra https://github.com/chantra what do you think?
— Reply to this email directly, view it on GitHub https://github.com/iovisor/bcc/pull/4997#issuecomment-2119727600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAF77DROQGITXS5HX7OYKTZDGGWXAVCNFSM6AAAAABHPIRQ7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJZG4ZDONRQGA . You are receiving this because you were mentioned.Message ID: @.***>
If bcc-devel requires llvm-devel, I suppose the problem is because we pull llvm-config.h in bcc_module.h which is public? Moving llvm-config.h to private only headers should do the job.
Can you list the public headers and we can work on moving this include out of the way.
For packaging, this should only be a build dependency right
Not sure about Debian, but on the RPM side, even though llvm-devel is a build-time dependency for ProcMon-for-Linux, it should be listed as a runtime dependency for bcc-devel to get it transitively installed; otherwise llvm-devel do not get installed along with bcc-devel.
The follow graph depicts the dependency chain:
ProMon (build-time dependency with "BuildRequires: bcc-devel") --> bcc-devel (runtime dependency with "Requires: llvm-devel") --> llvm-devel
If bcc-devel requires llvm-devel, I suppose the problem is because we pull llvm-config.h in bcc_module.h which is public? Moving llvm-config.h to private only headers should do the job.
I think that will work
Can you list the public headers and we can work on moving this include out of the way.
The public headers I founds are:
- BPF.h
- BPFTable.h
- bcc_common.h
- bcc_elf.h
- bcc_exception.h
- bcc_proc.h
- bcc_syms.h
- bcc_usdt.h
- bcc_version.h
- bpf_module.h
- file_desc.h
- libbpf.h
- perf_reader.h
- table_desc.h
- table_storage.h
So bpf_module.h should be the one that need modification.
#5018 should fix this issue. @shunghsiyu could you confirm the package change are fine? cc @yonghong-song