On Fri, 2021-06-11 at 23:20 +0100, Luca Boccassi wrote: > On Fri, 2021-06-11 at 23:17 +0100, Luca Boccassi wrote: > > On Fri, 2021-06-11 at 13:08 -0700, Andrii Nakryiko wrote: > > On Fri, Jun 11, 2021 at 1:00 PM Arnaldo Carvalho de Melo > > <arnaldo.melo@xxxxxxxxx> wrote: > > > > > > Em Fri, Jun 11, 2021 at 12:34:13PM -0700, Andrii Nakryiko > > > escreveu: > > > > On Thu, Jun 10, 2021 at 10:31 AM Arnaldo Carvalho de Melo > > > > <arnaldo.melo@xxxxxxxxx> wrote: > > > > > > > > > > Em Tue, Jun 08, 2021 at 12:50:13AM +0530, Deepak Kumar Mishra > > > > > escreveu: > > > > > > CMakeLists.txt does not allow creation of static library > > > > > > and > > > > > > link applications > > > > > > accordingly. > > > > > > > > > > > > Creation of SHARED and STATIC should be allowed using - > > > > > > DBUILD_SHARED_LIBS > > > > > > If -DBUILD_SHARED_LIBS option is not supplied, > > > > > > CMakeLists.txt > > > > > > sets it to ON. > > > > > > > > > > > > Ex: > > > > > > cmake -D__LIB=lib -DBUILD_SHARED_LIBS=OFF .. > > > > > > cmake -D__LIB=lib -DBUILD_SHARED_LIBS=ON .. > > > > > > > > > > Had to do some fixups due to a previous patch touching > > > > > CMakeLists.txt, > > > > > please check below. > > > > > > > > > > I tested it and added some performance notes. > > > > > > > > Hey Arnaldo, Deepak, > > > > > > > > I think this commit actually breaks libbpf's CI (see [0]) and > > > > my > > > > local > > > > setup as well (see output below). It seems like now we are > > > > using > > > > system-wide libbpf headers, while still building local libbpf > > > > sources. > > > > This is pretty bad because system-wide headers might be too old > > > > or > > > > just missing. > > > > > > I can't check this right now, but isn't this related to this one > > > instead? > > > > Heh, I beat you by 5 minutes ;) > > > > > > Hi, > > > > This should not be the case - the local paths are added to CMake > > and > > should win, unless something is going wrong - which is of course > > possible. A quick build of the current tip of the master branch > > would > > seem to confirm things are working - building with - > > DLIBBPF_EMBEDDED=off (which does force to use the system library, > > and > > defaults to on) the build fails, while building without any options > > on > > a new tree the build succeeds. > > > > I'll fetch the script and try to reproduce, as it might be using > > other > > options - I assume it's this one, right? > > > > https://github.com/libbpf/libbpf/blob/master/travis-ci/vmtest/build_pahole.sh > > Right, so this script is using the CMake option "-D__LIB=lib", and > the > issue is reproducible when that happens, on a clean tree without any > other options, which is indeed wrong. I was not aware of that so > didn't > test with it, apologies. > I'll see if I can come up with a fix, if noone else beats me to it. > Actually that was my mistake, used the wrong build tree (sorry, it's late!). I can however reproduce the issue in a chroot running the libbpf CI script. Still looking. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
