On some distro, static libraries are shipped in a separate package.
Look for either a static or dynamic libbpf, and only fail if neither is found.

Currently when building with CMAKE_USE_LIBBPF_PACKAGE we assume
that 'source' package is available to build libbcc_bpf libraries.

However It turned on that using debugsource (in Fedora) package is
not suitable or even possible, so we are switching to use the
libbpf-static package instead.

Adding libbpf-static package detection and removing source
package detection.

Using ar to extract objects from archive and linking them
with both libbcc_bpf.so and libbcc_bpf.a.

Using always uapi headers from the latest libbpf Github repo,
because there are not packaged, but they are backwards compatible,
so it's no problem to have older libbpf package with newer
uapi headers.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>

Which links libbpf.so dynamicaly, instead of its current
static inclusion in libbcc.so.

The compilation needs to define CMAKE_USE_LIBBPF_PACKAGE
variable to enable search for libbpf package. If the package
is found it is used to build all the bcc libs.

The libbcc.so and libbcc_bpf.so (and their static versions)
remain the same.

The new library libbcc-no-libbpf.so is built from all libcc.so
sources including libbpf_bcc.so's sources: libbpf.c perf_reader.c
and dynamically linked to libbpf.so library.

With libbcc-no-libbpf.so symbols are versioned, so there's
no chance of being mixed:

Symbols exported from libbpf.so:

  $ objdump -T /usr/lib64/libbpf.so | grep bpf_map_lookup_elem
  0000000000006df0 g    DF .text  000000000000006e  LIBBPF_0.0.1 bpf_map_lookup_elem
  0000000000006e60 g    DF .text  0000000000000076  LIBBPF_0.0.2 bpf_map_lookup_elem_flags

Symbol needed by libbcc-no-libbpf.so:

  $ objdump -T /opt/bcc/lib64/libbcc-no-libbpf.so | grep bpf_map_lookup_elem
  0000000000000000      DF *UND*  0000000000000000  LIBBPF_0.0.1 bpf_map_lookup_elem

Symbols exported by current libbcc.so:

  $ objdump -T /opt/bcc/lib64/libbcc.so | grep bpf_map_lookup_elem
  00000000023ad843 g    DF .text  0000000000000082  Base        bpf_map_lookup_elem_flags
  00000000023ad7d3 g    DF .text  0000000000000070  Base        bpf_map_lookup_elem

Besides that it's better to share common source of libbpf code,
it also prevents issues when having application that links to
libbpf and libbcc, where you could end up conflicting functions
and segfaults if those 2 libbpf libs are not on the same version.

All installed libraries now:

  total 259096
  lrwxrwxrwx. 1 root root        15 Nov  8 15:24 libbcc_bpf.so -> libbcc_bpf.so.0
  lrwxrwxrwx. 1 root root        20 Nov  8 15:24 libbcc_bpf.so.0 -> libbcc_bpf.so.0.11.0
  -rwxr-xr-x. 1 root root    453416 Nov 11 17:03 libbcc_bpf.so.0.11.0
  lrwxrwxrwx. 1 root root        21 Nov  8 15:24 libbcc-no-libbpf.so -> libbcc-no-libbpf.so.0
  lrwxrwxrwx. 1 root root        26 Nov  8 15:24 libbcc-no-libbpf.so.0 -> libbcc-no-libbpf.so.0.11.0
  -rwxr-xr-x. 1 root root 132276312 Nov 11 17:04 libbcc-no-libbpf.so.0.11.0
  lrwxrwxrwx. 1 root root        11 Nov  8 15:24 libbcc.so -> libbcc.so.0
  lrwxrwxrwx. 1 root root        16 Nov  8 15:24 libbcc.so.0 -> libbcc.so.0.11.0
  -rwxr-xr-x. 1 root root 132579280 Nov 11 17:04 libbcc.so.0.11.0
  drwxr-xr-x. 2 root root        23 Nov 11 21:49 pkgconfig

Signed-off-by: Jiri Olsa <jolsa@kernel.org>