[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <44ec7cbd-43fb-4363-7d8d-2e49ccb926e4@iogearbox.net>
Date: Sat, 23 Mar 2019 01:38:20 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: ast@...nel.org, sdf@...gle.com, bpf@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH bpf 1/2] bpf, libbpf: fix version info and add it to
shared object
On 03/23/2019 01:28 AM, Stanislav Fomichev wrote:
> On 03/23, Daniel Borkmann wrote:
>> On 03/23/2019 01:09 AM, Stanislav Fomichev wrote:
>>> On 03/23, Daniel Borkmann wrote:
>> [...]
>>>> +$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
>>>> + $(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_VERSION) \
>>> Shouldn't it be -soname,libbpf.so.$(VERSION) ?
>>
>> The above is generating libbpf.so.0.0.2, and with the below two we generate
>> symlinks to it. libbpf.so.$(VERSION) would result in libbpf.so.0 otherwise
>> which we want to be a symlink instead. The workflow I've been following is
>> similar to fe316723a810 ("tools lib traceevent: Add version for traceevent
>> shared object").
> Sorry, I was not clear enough, I was talking about -Wl,-soname linker option.
> Shouldn't it contain "major" version?
>
> $ readelf -d libtraceevent.so.1.1.0 | grep SONAME
> 0x000000000000000e (SONAME) Library soname: [libtraceevent.so.1]
>
> With your patch applied:
> $ readelf -d libbpf.so.0.0.2 | grep SONAME
> 0x000000000000000e (SONAME) Library soname: [libbpf.so.0.0.2]
>
> ^^^^^^^^^^^^^
> libbpf.so.0 ?
Heh, agree, good catch indeed. v2 coming.
Powered by blists - more mailing lists