From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] mk: --no-as-needed by default for linux exec-env
Date: Thu, 30 Oct 2014 16:20:17 +0000 [thread overview]
Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004E9A23A@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20141030140110.GE24783@hmsreliant.think-freely.org>
> > 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
> > 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'
> >
next prev parent reply other threads:[~2014-10-30 16:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 10:57 Sergio Gonzalez Monroy
2014-10-30 11:05 ` Gonzalez Monroy, Sergio
2014-10-30 14:01 ` Neil Horman
2014-10-30 16:20 ` Gonzalez Monroy, Sergio [this message]
2014-10-30 19:21 ` Neil Horman
2014-10-31 9:02 ` Gonzalez Monroy, Sergio
2014-11-05 15:02 ` De Lara Guarch, Pablo
2014-11-28 15:35 ` Thomas Monjalon
2014-11-29 15:02 ` Neil Horman
2014-11-29 20:20 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=91383E96CE459D47BCE92EFBF5CE73B004E9A23A@IRSMSX108.ger.corp.intel.com \
--to=sergio.gonzalez.monroy@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).