Re: Latest libbpf fails to load programs compiled with old LLVM

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> On Mon, Dec 7, 2020 at 8:51 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>>
>> > On Mon, Dec 7, 2020 at 8:15 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> >>
>> >> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>> >>
>> >> > On Mon, Dec 7, 2020 at 3:03 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> >> >>
>> >> >> Wait, what? This is a regression that *breaks people's programs* on
>> >> >> compiler versions that are still very much in the wild! I mean, fine if
>> >> >> you don't want to support new features on such files, but then surely we
>> >> >> can at least revert back to the old behaviour?
>> >> >
>> >> > Those folks that care about compiling with old llvm would have to stick
>> >> > to whatever loader they have instead of using libbpf.
>> >> > It's not a backward compatibility breakage.
>> >>
>> >> What? It's a change in libbpf that breaks loading of existing BPF object
>> >> files that were working (with libbpf) before. If that's not a backward
>> >> compatibility break then that term has lost all meaning.
>> >
>> > The user space library is not a kernel.
>> > The library will change its interface. It will remove functions, features, etc.
>> > That's what .map is for.
>>
>> Right, OK, so how do I use .map to get the old behaviour here? That's
>> all I'm asking for, really...
>
> Fix old llvm. The users would have to upgrade either from llvm 7.x to
> 7.x+1 or to llvm 10+.

Right, so by "we keep a stable interface" you mean "we expect you to
upgrade your entire toolchain every time you update the library". Gotcha!
I'll rectify my newspeak dictionary straight away - doubleplusgood!

-Toke