Always build libbpf as a PIE

[jordalgo]

This is to fix an error sometimes seen when compiling with gcc,
whereby the position independent sched ext rust libraries
don't play nicely with the libbpf library if it's not also built
as position independent.

This also explicitly sets the rustc relocation-mode to "pic",
which is the default (just so this doesn't accidentally change
out from under us).

[Byte-Lab]

I'm not understanding what the meaning is of -fPIE for a static library. My guess is that this implies -fPIC or something? Anyways, I think if we're going to do this we should just always build with -fPIE. Clearly it's something that rustc requires.

[htejun]

Reads to me it's position independent but can't be linked to create dynamic libs. No idea why it's needed.

[Byte-Lab]

Yeah, I've just never seen -fPIE used to create a lib. I thought it was always -fPIC given that it's not creating an executable.

[Byte-Lab]

By the way, not sure it matters but I believe we should only need to build libbpf.a target

[htejun]

Is there a reason for excluding -O? Why don't we want to be synced with how other parts of scx is built?

[htejun]

I don't think this is a reliable way to detect gcc. meson has compiler.has_argument() test, so maybe test whether -fPIE is supported there and add that to build flags?

[Byte-Lab]

Or let's just always build with -fPIE to minimize the build complexity / variance?

[htejun]

Reads to me it's position independent but can't be linked to create dynamic libs. No idea why it's needed.

[htejun]

Is there a reason for excluding -O? Why don't we want to be synced with how other parts of scx is built?

[jordalgo]

Limited the scope of these changes. Luckily meson has a "pie" option for compiling executables so we'll automatically get the right flag for the selected compiler (tested with both clang and gcc).

[jordalgo]

Is there a reason for excluding -O? Why don't we want to be synced with how other parts of scx is built?

@Decave Mentioned that we should always be compiling libbpf with -O2 -- I guess the question is - why don't we do this by default for our other exes/libs?

[htejun]

Is there a reason for excluding -O? Why don't we want to be synced with how other parts of scx is built?

@Decave Mentioned that we should always be compiling libbpf with -O2 -- I guess the question is - why don't we do this by default for our other exes/libs?

Because optimized builds are slow, debugging can be painful and should by controlled by setting buildtype appropriately. I don't know whether we can make meson default to release builds, which would be fine, but it'd be annoying if the buildtype is set to debug and everything else is built accordingly but just libbpf isn't.

[Byte-Lab]

Is there a reason for excluding -O? Why don't we want to be synced with how other parts of scx is built?

@Decave Mentioned that we should always be compiling libbpf with -O2 -- I guess the question is - why don't we do this by default for our other exes/libs?

Because optimized builds are slow, debugging can be painful and should by controlled by setting buildtype appropriately. I don't know whether we can make meson default to release builds, which would be fine, but it'd be annoying if the buildtype is set to debug and everything else is built accordingly but just libbpf isn't.

Well, the counter-argument to that is that libbpf is just a dependency the same as any other whose build type we don't control. In my mind, having libbpf as a submodule was more so meant to be a convenience to avoid versioning issues than a way to control how we compile libbpf. Given how closely it interfaces with the scheduler though, I'm fine with just using the meson build flags for it.