In the logic we generate for opening the skeleton, we unconditionally work with some bpf_object_open_opts object, even if the user did not customize anything. That's fine in principle, but it can trigger a bug when a old system libbpf is used and which violates its forward compatibility guarantees.
With this change we work around the issue by invoking the bpf_object__open_skeleton() libbpf function with a NULL pointer if SkelBuilder::open() instead of SkelBuilder::open_opts() is being used. This is generally the common case and so we work around the underlying libbpf bug until fixed and new releases rolled out to various distributions.
In the logic we generate for opening the skeleton, we unconditionally work with some bpf_object_open_opts object, even if the user did not customize anything. That's fine in principle, but it can trigger a bug when a old system libbpf is used and which violates its forward compatibility guarantees. With this change we work around the issue by invoking the bpf_object__open_skeleton() libbpf function with a NULL pointer if SkelBuilder::open() instead of SkelBuilder::open_opts() is being used. This is generally the common case and so we work around the underlying libbpf bug until fixed and new releases rolled out to various distributions.
Closes: #927