On Wed, Aug 28, 2019 at 3:53 PM Aaron Conole <acon...@redhat.com> wrote: > > Christian Ehrhardt <christian.ehrha...@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.ehrha...@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?
