Re: [dpdk-dev] [PATCH] mk: --no-as-needed by default for linux exec-env

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, Oct 30, 2014 at 04:20:17PM +0000, Gonzalez Monroy, Sergio wrote:
> > > Basically, Ubuntu GCC is always passing --as-needed to the linker
> > > which causes some Linking issues for us.
> > Can you elaborate here?
> > Neil
> > 
> Sorry, probably I could have given more info about the issue.
> 
> Currently if we build DPDK with shared libs on Ubuntu, build process fails when it tries to link test apps with following error:
> /tmp/DPDK-1.8-RC4/x86_64-native-linuxapp-gcc/lib/librte_eal.so: undefined reference to `rte_mempool_lookup'
> /tmp/DPDK-1.8-RC4/x86_64-native-linuxapp-gcc/lib/librte_eal.so: undefined reference to `rte_mempool_create'
> 
> We can work around that error by building with EXTRA_LDFLAGS='--no-as-needed' because as the link about
> Debian/Ubuntu toolchain mention, they always pass the '--as-needed' flag to the compiler.
> 
> I see a couple of issues with this flag in our current build process (this is from my own testing, I could be missing something here):
> - We do not set dependencies for DPDK shared libraries. This is the cause of the error shown above.
>    As the libs have no dependencies (librte_eal has no dependency on librte_mempool) and the app itself is not
>    referencing the functions, librte_mempool is 'not needed' and the app fails to link when it tries to resolve librte_eal symbols.
> - We push PMDs into the binary without being reference with --whole-archive but that does not seem to be the
>    case if we previously have --as-needed (maybe there is a way around this? )
> 
> I have posted an RFC about improving the current build process, mostly affecting shared lib building.
> By adding dependencies we could fix the error but not the second issue with PMDs.
> 
> I guess now it makes more sense what I mention below about not being sure about this patch, cause is not tackling the real issue here.
> 
> Hope this helps.
> 
> Thanks,
> Sergio
> 
Thank you, it does, though it raises an intersting question.  By flipping that
switch around you definately solve the problem at hand, but you don't really
close the bug completely.  The problem arises because librte_eal doesn't add a
DT_NEEDED entry for librte_mempool despite the fact that it references symbols
in that library.  It does this because we don't explicitly link with
-lrte_mempool when we build librte_eal.  Normally thats ok, because libraries
don't load on their own, and every application that needs to link rte_eal also
needs to link rte_mempool, so the symbols happen to resolve properly.  But that
may not always be the case for all libraries. It gives rise to the argument that
building a single large library may be preferable, as we might otherwise need to
create dependency chains where libraries fully specify their dependencies in
their DT_NEEDED sections

Neil

> > > I'm not entirely sure that we should patch this issue or just add to the
> > release notes.
> > > Currently we can work around this by setting EXTRA_LDFLAGS='--no-as-
> > needed'
> > >
>