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

[Aaron Conole]

Aaron Conole <aconole at redhat.com> writes:

> Christian Ehrhardt <christian.ehrhardt at canonical.com> writes:
>
>> 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?
>
> 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.

Oops - forgot to push the revert:

https://travis-ci.org/orgcandman/dpdk/builds/577918381 is the correct
build.

Sorry.

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