[dpdk-dev] [PATCH] mk: fix underlinking issues of most librte libraries

Panu Matilainen pmatilai at redhat.com
Tue Jun 7 11:25:26 CEST 2016


On 06/07/2016 11:23 AM, Thomas Monjalon wrote:
> 2016-05-24 12:56, Panu Matilainen:
>> On 05/20/2016 08:08 PM, Thomas Monjalon wrote:
>>> 2016-05-20 18:50, Christian Ehrhardt:
>>>> The individual libraries have various cross dependencies.
>>>> This is already refelcted in the DEPDIR dependency, but not yet in
>>>> proper DT_NEEDED flags in the .so's.
>>>> This adds the -l flags so that is properly stored in the .so's ELF
>>>> headers.
>>>
>>> Why not filling LDLIBS by parsing DEPDIRS-y in rte.lib.mk?
>>>
>>
>> A fair question :) The thought has passed my mind too, but I thought
>> it'd be too messy with differing library vs directory names and other
>> exceptions. But in reality manually maintained separate LDLIBS is only
>> going to get out of sync sooner or later, and turns out its not that bad
>> anyway:
>>
>> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
>> index b420280..88b4e98 100644
>> --- a/mk/rte.lib.mk
>> +++ b/mk/rte.lib.mk
>> @@ -77,6 +77,12 @@ else
>>   _CPU_LDFLAGS := $(CPU_LDFLAGS)
>>   endif
>>
>> +# Translate DEPDIRS-y into LDLIBS
>> +IGNORE_DEPS = -lrte_eal/% -lrte_net -lrte_compat
>
> We need some comments to explain why they are ignored.

Yup. It'd be more clear if this filtering was done before translating 
directories to -lrte_foo but this was the first variant I came across 
that worked :) The issue is that librte_eal/common, librte_net and 
librte_compat are common directory dependencies but no actual library is 
generated from them so they just need to be weeded out of the equation, 
the revised version makes this more clear.

>
>> +_LDDIRS = $(subst librte_ether,libethdev,$(DEPDIRS-y))
>> +_LDDEPS = $(subst lib/lib,-l,$(_LDDIRS))
>> +LDLIBS += $(filter-out $(IGNORE_DEPS), $(_LDDEPS))
>
>> I'm also sure somebody more familiar with gmake could improve it, but it
>> seems to work quite fine here. I'll wait a bit to see if there are other
>> suggestions before sending it as a proper patch.
>
> I'm familiar with gmake and I do not think it can be improved more ;)
> Please send a patch. Thanks
>

Ok, will do.

	- Panu -


More information about the dev mailing list