The desired end effect of build is to have a combined library, and it will
not be going away. The upstream combined library is considered bloatware
which creates issues when library versions start moving, so force the
issue by using linker script instead.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
Some makefiles refer to the scripts in the directory, and eg
pktgen make fails without the script foo. To allow these builds
to succeed, include the scripts directory
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
As part of the dpdk solution, we include an extensible profile option
which automatically configures the dpdk 'RTE' environment
variables. However, these will create build issues if we attempt to
build packages on a machine which has these packages installed. To
combat this, we undefine these variables in the build environment.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
Currently, dpdk ships with cpu_layout.py and dpdk_bind_tools.py to
assist with common workflow. Create a tools package which can encompass
these items.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
By changing the array size to work around a spurious warning from gcc,
we run the risk of breaking future code which may rely on the array's
size (using, ex: sizeof). Since this array-bounds failure is the product
of gcc-5.x, and not actually an error here, it can safely be ignored.
We need to keep the -Wformat warning, however, because that will trigger
build errors in some of the PMD builds.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
Upstream makefiles only enable -fPIC for shared libs, but on x86_64
its needed for static libs as well when combined with dynamic linking
(otherwise building eg OVS fails with relocation R_X86_64_32 errors)
Ciuld arch-conditionalize it but then this only builds for x86_64 atm...
- Move static libraries to -devel, there's no point in having them
in a "runtime" package anyway
- Add dpdk-static = %{version}-%{release} provide to -devel
- Have the main package always own the private library directory though
Upstream has an option to build a combined library but it'll clash
with symbol/library versioning once it lands. Use a linker script
instead of an actual ELF DSO to side-step the issue.
GROUP() is used instead of INPUT() to avoid the need for manual
ordering of the umphteen libraries.
(yes, Fedora recommendation is misguided wrt this: %global has unwanted
side-effects when used blindly for "everything", greetings from your
friendly former rpm maintainer)
- Drop unused destdir macro from the spec while at it
- Use EXTRA_CFLAGS to include standard Fedora compiler flags in build
- Set CONFIG_RTE_MACHINE=default to build for least-common-denominator machines
- Turn-off build of librte_acl, since it does not build on default machines
- Turn-off build of physical device PMDs that require kernel support
- Clean-up the install rules to match current packaging
- Correct changelog versions 1.0.7 -> 1.7.0
- Remove ix86 from ExclusiveArch -- it does not build with above changes
