On 04/03, Luca Boccassi wrote: >On Wed, 2019-04-03 at 22:43 +0800, Ye Xiaolong wrote: >> On 04/03, Luca Boccassi wrote: >> [snip] >> > > Got it. >> > > >> > > In above steps, 'libbpf' also build from kernel source tree, will >> > > it >> > > be problem >> > > in you builds to not have it build from source? >> > > >> > > If not, taking into account that xsk.h also will be fixed, only >> > > 'tools/include/asm/barrier.h' remains the problem, and it looks >> > > like >> > > it can be >> > > solved, please check above. >> > >> > libbpf is already packaged separately in Debian and I think other >> > distros will follow soon, so it's all good for me once the barrier >> > issue is solved. >> > >> > https://packages.debian.org/buster/libbpf-dev >> > >> > >> > From the makefile's perspective it should not matter where it comes >> > from - the headers should be expected to be in /usr/include and the >> > library in /usr/lib* - and pkg-config can help with that if >> > available. >> > And if a user wants to use a custom path, then it's no different >> > than >> > any of the other dependencies on other external libraries >> >> From tools/lib/bpf/Makefile, after make install_lib and make >> install_headers, >> the headers and library would be put in /usr/local/include/bpf and >> /usr/local/lib*, >> Is it ok? > >Yes certainly that's fine, that's expected for local installations, and >users can specify a prefix with the upstream's makefile if they want to >install somewhere else.
In my local test, if I run `make install_lib` to install the libbpf.so to /usr/local/lib64, `-lbpf` specified in af_xdp pmd still fails to find the library, the build would end up with a lot of undefined references which are defined in libbpf. It means during dpdk compilation, it won't search libraries in /usr/local/lib*, right? Install the libbpf to /usr/lib64 via `make install_lib prefix=/usr` doesn't have this issue, so shall I just document it in af_xdp.rst or there is other proper way to do it? Thanks, Xiaolong > >-- >Kind regards, >Luca Boccassi
