On 3/25/19 10:21 AM, Michal Rostecki wrote: > On Mon, Mar 25, 2019 at 09:03:11AM -0700, Alexei Starovoitov wrote: >>>> 2) There's already bcc-devel's libbpf library packaged: >>>> >>>> $ rpm -qf /usr/lib64/libbpf.so >>>> bcc-devel-0.8.0-1.fc28.x86_64 >>>> >>>> so there's a conflict.. any chance we could rename libbpf to >>>> something else like: >>>> >>>> libbpf2.so >>>> libbpfobject.so >>>> libbpfbest.so >>>> ...? >>> >>> I don't think we should rename the official libbpf package, this will >>> just create plain confusion and will make it much harder for potential >>> users to adapt in the long-term since we aim for /everyone/ to consume >>> official libbpf library instead of hacking their own. >>> >>> I think bcc folks are migrating to official libbpf as well, at least >>> that was my impression. Imho, this would need fixing on bcc side then. >> >> bcc migrated to libbpf some time ago. > > And the libbpf.so file which is installed with bcc is "our" libbpf. bcc > simply uses libbpf (from the auto-synced standalone repo[0]) as a > submodule[1]. To package libbpf and bcc properly in Linux distros we > need a possibility to use bcc with shared libbpf library - which > probably can be achiveved by small change in bcc's CMakeLists.txt. I think we should rename bcc libbpf.so to a different name (maybe libbcc_bpf.so) to avoid confusions between bcc libbpf and libbpf repo. The bcc libbpf.so is different from libbpf repo it contains some wrappers... I will propose to iovisor/bcc mailing list. > > The standalone repo[0] might be a better base for creating a package > than full kernel sources. And using %soversion%+git%sha% (i.e. > 0.0.2+git33b017) might be a better version pattern of that package. > > Cheers, > Michal > > [0] https://github.com/libbpf/libbpf > [1] https://github.com/iovisor/bcc/blob/master/CMakeLists.txt#L12-L16 >
