[dpdk-dev] [PATCH] build: avoid --as-needed as it causes overlinking

[Christian Ehrhardt]

On Wed, Aug 28, 2019 at 3:53 PM Aaron Conole <aconole at redhat.com> wrote:
>
> Christian Ehrhardt <christian.ehrhardt at canonical.com> writes:
>
> > A while ago telemetry was added in 57ae0ec6 and it also added as-needed
> > to config/meson.build. This seems no more needed these days as due to other
> > build changes the ordering in buildlogs is:
> >   [...] -lrte_telemetry [...] -Wl,--no-as-needed [...]
> > Which means telemetry no more benefits from --no-as-needed anyway.
> >
> > Overlinking problems get triggered by the meson generated pkgconfig which
> > will have:
> >    [...] -Wl,--no-as-needed <somelibsusedbydpdk>
> > This will overlink <somelibs> and in addition anything that follows
> > as it also doesn't wrap back to --as-needed. So if a projects includes
> > dpdk libs + <other> it will also consider <other> with --no-as-needed.
> >
> > Fixes: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1841759
> >
> > Signed-off-by: Christian Ehrhardt <christian.ehrhardt at canonical.com>
> > ---
>
> Hi Christian,
>
> I agree this is something to be fixed.  It will need additional work,
> though:
>
>   https://travis-ci.com/ovsrobot/dpdk/builds/124909245
>

Thanks for the Link Aaron, yet I'm puzzled what to do there atm.

The kind of error I found in the failing logs were misleading at first:
- linker can't find -lvirt / -lpqos / ...
  well the test env needs to install them, maybe it was added as
dependency by accident before?
  I'd understand (due to the change) if it would complain about missing symbols
  (no more added due to as-needed, but then for some reason needed)
  But this is vice versa, it just doesn't find the libs in the build env
- error: unrecognized command line option '-Wformat-truncation'
  I don't see how I'd cause this ...
=> Maybe this is just an artifact that is even part of the normal/good tests?


Comparing former logs - last good test was
https://travis-ci.com/ovsrobot/dpdk/builds/124875383
This first seemed more helpful.

DPDK:fast-tests / eal_flags_w_opt_autotest  FAIL
DPDK:fast-tests / func_reentrancy_autotest  FAIL
DPDK:fast-tests / mbuf_autotest         FAIL
DPDK:fast-tests / mempool_autotest      FAIL
DPDK:fast-tests / ring_pmd_autotest     FAIL
DPDK:fast-tests / sched_autotest        FAIL
DPDK:fast-tests / table_autotest        FAIL
[...]
Overall about 14/60 of the tests failed with no recognizable pattern
why just those and not the others.

I only see "Full log written ... on_error", so I can't directly
compare how a good run would look in the configure/build stage.
Looking just at the bad case there are plenty of messages like
- "no available hugepages"
- "cannot reserve memory", ..
But all those indicate more a flaky test(-env) than an error in the
commit, there must be more to it.

@Aaron is there a good way to get the rest of the log for a good case
to compare?

Maybe I'm yet to blind for all the potential side effects of the change?