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@gmail.com> 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@gmail.com> 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