The recipe rte.hostapp.mk does not build in hostapp/ anymore.
Fixes: 98b0fdb0ff ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
When compiling the drivers, some code is generated with pmdinfogen.
A fresh parallel build can fail if a driver is compiled before pmdinfogen:
build/buildtools/dpdk-pmdinfogen: Permission denied
There was a dependency declared in drivers/Makefile but it cannot work
because this file is based on mk/rte.subdir.mk which do not handle
dependencies.
It is fixed by declaring the whole buildtools as (order only) prerequisite
of drivers.
Fixes: cb6696d220 ("drivers: update registration macro usage")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
pmdinfogen is a tool used to parse object files and build json strings for
use in later determining hardware support in a dso or application binary.
pmdinfo looks for the non-exported symbol names this_pmd_name<n> and
this_pmd_tbl<n> (where n is a integer counter). It records the name of
each of these tuples, using the later to find the symbolic name of the
pci_table for physical devices that the object supports. With this
information, it outputs a C file with a single line of the form:
static char *<pmd_name>_driver_info[] __attribute__((used)) = " \
PMD_DRIVER_INFO=<json string>";
Where <pmd_name> is the arbitrary name of the pmd, and <json_string> is the
json encoded string that hold relevant pmd information, including the pmd
name, type and optional array of pci device/vendor ids that the driver
supports.
This c file is suitable for compiling to object code, then relocatably
linking into the parent file from which the C was generated. This creates
an entry in the string table of the object that can inform a later tool
about hardware support.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Remy Horton <remy.horton@intel.com>
The physically linked-together combined library has been an increasing
source of problems, as was predicted when library and symbol versioning
was introduced. Replace the complex and fragile construction with a
simple linker script which achieves the same without all the problems,
remove the related kludges from eg mlx drivers.
Since creating the linker script is practically zero cost, remove the
config option and just create it always.
Based on a patch by Sergio Gonzales Monroy, linker script approach
initially suggested by Neil Horman.
Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Suggested-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
The real installation was called "binary install" and was done
after the build when DESTDIR was specified.
Remove this limitation and move the code in install rule only.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
CONFIG_RTE_BUILD_SHARED_LIB and CONFIG_RTE_BUILD_COMBINE_LIBS does not
have quotes in their values (only y or n). That's why the variables
RTE_BUILD_SHARED_LIB and RTE_BUILD_COMBINE_LIBS are always identical to
their CONFIG_ counterpart, and are useless.
In order to have consistent naming of config options in the makefiles,
these options are removed and the "CONFIG_ prefixed" variables are used.
Fixes: e25e4d7ef1 ("mk: shared libraries")
Fixes: 4d3d79e7a5 ("mk: combined library")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
When a target is finished building, it reports just "Build complete".
When building multiple targets simultaneously, e.g.
make install T=x86_64-native-linuxapp-*
and one target fails, it's not always obvious which of the builds
failed. To help this, we add the actual target that is completed to the
"Build complete" message.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
The combined lib was being created after building the lib root dir.
With the new directory hierarchy, it should be created after the
drivers root dir instead.
Fixes: 980ed498eb ("drivers: create new directory")
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Tested-by: Li Wei <lw@cn.fujitsu.com>
This commit removes trailing whitespace from lines in files. Almost all
files are affected, as the BSD license copyright header had trailing
whitespace on 4 lines in it [hence the number of files reporting 8 lines
changed in the diffstat].
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
[Thomas: remove spaces before tabs in libs]
[Thomas: remove more trailing spaces in non-C files]
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Trying to install headers for an external library using DPDK exported makefile
rte.extshared.mk results in following error :
$ cd dpdk
$ make install DESTDIR=/home/marchand/myapp/staging/plop T=x86_64-default-linuxapp-gcc
$ cd ~/myapp
$ make RTE_SDK=/home/marchand/myapp/staging/plop RTE_TARGET=x86_64-default-linuxapp-gcc
CC plop.o
LD plop.so
SYMLINK-FILE include/plop.h
/bin/sh:
/home/marchand/myapp/staging/plop/scripts/relpath.sh: No such file or directory
ln: `/home/marchand/myapp/build/include' and `./include' are the same file
make[1]: *** [/home/marchand/myapp/build/include/plop.h] Error 1
make: *** [all] Error 2
This comes from the fact that DPDK only installs its mk/ directory while some
makefiles require the scripts/ directory content as well.
So install missing files from scripts/.
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This reverts commits
a0cdfcf9 (use pcap-config to guess compilation flags),
ef5b2363 (fix build with empty LIBPCAP_CFLAGS) and
60191b89 (fix build when pcap_sendpacket is unavailable).
These patches are creating more problems than solving the initial one
(which was a build error with too old pcap libraries).
Since old pcap libraries are not that common, just revert them.
Reported-by: Meir Tseitlin <mirots@gmail.com>
Reported-by: Mats Liljegren <mats.liljegren@enea.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
In rte.sdkbuild.mk with CONFIG_RTE_LIBRTE_PMD_PCAP=y,
we error-exit if LIBPCAP_CFLAGS is empty.
On some distros (e.g., Centos 6.4), it is normal for "pcap-config --cflags"
to output only a newline, because pcap header files reside in /usr/include/.
Solution is to remove the line that checks whether LIBPCAP_CFLAGS is empty.
Signed-off-by: Robert Sanford <rsanford@prolexic.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Use pcap-config to populate CFLAGS and LDFLAGS.
LIBPCAP_CFLAGS and LIBPCAP_LDFLAGS can be used to override this (useful when
cross-compiling).
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This will install the binary sdk (bin + modules + libs + headers + mk)
in the specified directory.
This directory can be used as RTE_SDK by external applications.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Changes to allow compilation and use on FreeBSD. Includes:
* contigmem and nic_uio driver for FreeBSD
* new EAL instance
* new "bsdapp" compilation target
* various compilation fixes due to differences between linux and freebsd
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>