[dpdk-dev] [PATCH v2 01/10] build: add an option to enable LTO build

Bruce Richardson bruce.richardson at intel.com
Tue Sep 24 12:25:35 CEST 2019


On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
> On 9/23/19 6:13 PM, Bruce Richardson wrote:
> [...]
> > However, testing on my system with the meson build, I'm getting lots of
> > link errors [See below]. Any suggestions?
> > 
> > /Bruce
> > 
> > /usr/bin/ld: /tmp/dpdk-testpmd.hncbtE.ltrans93.ltrans.o: in function `ena_stop':
> > <artificial>:(.text+0x9ed6): undefined reference to `rte_timer_stop'
> [...]
> 
> What is 'default_library'?  It should be 'shared' as mentioned in the
> docs.  The problem is that RTE_BUILD_SHARED_LIB is statically defined in
> rte_config.h used by meson build.  This results in broken static
> libraries (those that are using versioned symbols - like
> timer/lpm/distributor) - since the MAP_STATIC_SYMBOL macro defining the
> default alias is empty.  With LTO compiler (or rather linker) is quite
> aggressive in removing stuff that it thinks is not needed.
> 
> Regards
> Andrzej
> 
> PS. IMHO this SHARED_LIB define should be removed from the rte_config.h
> and meson.build should be updated to detect 'default_library' and add it
> as needed.  Don't know exactly how meson behaves if 'default_library' is
> 'both' - the docs say that it reuses objects from static build, so we
> might have to work around it for LTO & 'both'.

That proposal won't work either as we build both static and shared
libraries in all cases - the default_library value only affects whether the
test apps are linked against the .a or .so files.

The real issue seems to be that the compat.h header has different
compilation paths for static and shared libraries, which means that any C
file including it can't have a .o file that can be used for both a .a and a
.so simultaneously. Having it default to the shared library path seems to
work fine thus far, but with LTO it seems broken as you say. Adding Neil as
the original file author of this in case he has any suggestions here. I'd
really rather not have to go back to building .a's and .so's separately.

Regards,
/Bruce


More information about the dev mailing list