Christian Ehrhardt <christian.ehrha...@canonical.com> writes: > 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?
Not sure about this. It's strange to require that we *install* the libraries before we can unit test them. After all, if I'm going to potentially replace my previously installed libraries, I definitely want to know that the unit tests are passing. > 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? I don't think so - but there's a simple change. I've pushed to my own branch and you can see the builds: https://travis-ci.org/orgcandman/dpdk/branches using the same series_6154 branch name. > 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. Good question :) > 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. Okay. Fair enough. > @Aaron is there a good way to get the rest of the log for a good case > to compare? Let's wait for https://travis-ci.org/orgcandman/dpdk/builds/577910388 to spit out some details. > Maybe I'm yet to blind for all the potential side effects of the change?
