The object files are copied to prepare the internal combined library.
It must be disabled when building an external library.
It has been seen because the directory was missing:
examples/ethtool/lib/x86_64-native-linuxapp-gcc/build/lib:
No such file or directory
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
The initial problem has been seen while building mlx4 pmd as a shared
library on Ubuntu 14.04 (gcc 4.8.4-2ubuntu1~14.04).
Resulting .so will lack the DT_NEEDED entry for libibverbs:
marchand@ubuntu1404:~/dpdk$ ldd ./build/lib/librte_pmd_mlx4.so
linux-vdso.so.1 => (0x00007fff87ebb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ced21a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2ced821000)
And trying to load it in testpmd triggers this error:
[...]
EAL: librte_pmd_mlx4.so: undefined symbol: ibv_query_port
[...]
After some strace, the problem comes from the --as-needed option passed to the
linker.
It is safer to specify libraries we depend on after the objects we are linking
into a shared library, especially when the linker is invoked with options like
--as-needed.
Fixes: bef06a8a06 ("mk: set library dependencies in shared object file")
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
When using a linker option not known by the compiler like -rpath,
the library linkage was failing.
It is fixed by prefixing the option with -Wl, as it is done in other
makefiles.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Some .so libraries needs to be linked with external libraries. For that the
LDLIBS and EXTRA_LDFLAGS variables should be present on the link line when
those .so files are created. PMD Makefile is responsible for filling the
LDLIBS variable with the link to the external library it needs.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
When next ABI is enabled, the shared lib extension is .so.x.1.
That's why a double basename was introduced.
But the "ifeq NEXT_ABI" was forgotten, removing the .so
extension when NEXT_ABI is disabled.
It was preventing the linker from finding the .so libraries.
Fixes: 506f51cc0d ("mk: enable next abi preview")
Reported-by: John McNamara <john.mcnamara@intel.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
When a change makes really hard to keep ABI compatibility,
instead of waiting next release to break the ABI, it is smoother
to introduce the new code as a preview and disable it when packaging.
The flag RTE_NEXT_ABI must be used to "ifdef" the new code.
When the release is out, a dynamically linked application can use
the new shared libraries with the old ABI while developpers can prepare
their application for the next ABI by reading the deprecation notice
and easily testing the new code.
When starting the next release cycle, the "ifdefs" will be removed
and the ABI break will be marked by incrementing LIBABIVER. The map
files will also be updated.
The default value is enabled to be developer compliant.
The packagers must disable it as done in pkg/dpdk.spec.
When enabled, all shared library numbers are incremented by appending
a minor .1 to the old ABI number. In the next release, only impacted
libraries will have a major +1 increment.
The impacted libraries must provide an alternative map file to use
with this option.
The ABI policy is updated.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.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>
On Fedora 22, the "ar" binary operates by default in deterministic mode,
making the "u" parameter irrelevant, and leading to warning messages
getting printed in the build output like below.
INSTALL-LIB librte_kvargs.a
ar: `u' modifier ignored since `D' is the default (see `U')
There are two options to remove these warnings:
* add in the "U" flag to make "ar" non-deterministic again
* remove the "u" flag to have all objects always updated
This patch takes the second approach. It also explicitly adds in the "D"
flag to make behaviour consistent across different distributions which
may have different defaults.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
This is all-important now that the libraries are versioned: DT_SONAME
presence instructs the runtime dynamic linker to load the shared object
by the versioned name in DT_SONAME instead of the the unversioned symlink
name used during build.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
To differentiate libraries that break ABI, we add a library version number
suffix to the library, which must be incremented when a given libraries ABI is
broken. This patch enforces that addition, sets the initial abi soname
extension to 1 for each library and creates a symlink to the base SONAME so that
the test applications will link properly.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Add initial pass header files to support symbol versioning.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
It appeared in commit 21cdc2e77a ("fix 32-bit link with gcc")
that linker options must be prefixed by -Wl, when using CC.
So CPU_LDFLAGS is prefixed in rte.lib.mk.
Then commit 815cfb7925 ("fix link of combined shared library using CC")
introduced another prefixing of CPU_LDFLAGS in rte.sharelib.mk,
included in lib/Makefile.
Because CPU_LDFLAGS is an exported variable, the prefixing is done twice.
Initial patch of commit 815cfb7925 had a workaround but it hasn't
been applied in favor of this proper fix.
Now variables are not overriden when prefixing.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
The option "-z muldefs" was set only if not using ld directly.
By the way, this option seems to be a useless hack introduced
with shared and combined libraries support (e25e4d7ef1).
The clean approach is to remove it.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Incompatible libraries error when building shared libraries for 32bits on
a 64bits system.
Fix issue by passing CPU_CFLAGS to CC when LINK_USING_CC is enabled.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.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>
Some linker options were not prefixed by -Wl, when using CC:
-z muldefs
-melf_i386 (CPU_LDFLAGS in 32-bit config)
I didn't see any error with -z muldefs but it isn't documented in gcc
manual. So it's safer to explicitly pass it to the linker.
Also building 32-bit shared library raises this error:
gcc: error: unrecognized command line option ‘-melf_i386’
Using macro linkerprefix fixes it.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
The shared libraries built with the current makefile set produce static
libraries rather than actual shared objects. This is due to several missing
options that are required to correctly build shared objects using ld, as well as
a mis-specified -share option (which should be -shared). Switching to the use of
CC rather than LD and fixing the -shared option corrects these problems and
builds the DSOs correctly.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
