Re: libbpf packaging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jiri,

>>>>>> 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...
> 
> that'd be great first step.. then we could add libbpf
> package and make bcc depend on it as suggested by Michal
> 
>>
>> I will propose to iovisor/bcc mailing list.
> 
> please keep me in cc for that

Do not know your github name, so not able to cc you on the bcc pull 
request which changes library from libbpf.{a,so} to libbcc_bpf.{a,so}.
The below is the link:
    https://github.com/iovisor/bcc/pull/2290

> 
> thanks,
> jirka
> 
>>
>>>
>>> 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
>>>




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux