[dpdk-dev] [PATCH 2/2] mk: move PMD libraries to applications

Ferruh Yigit ferruh.yigit at intel.com
Tue Jan 31 15:36:17 CET 2017


On 1/31/2017 2:16 PM, Thomas Monjalon wrote:
> 2017-01-31 12:14, Ferruh Yigit:
>> Same PMDs provide device specific APIs. Bond and xenvirt are existing
>> samples for this.
> 
> s/Same/Some/
> 
>> And since these are PMD libraries, there are two options on how to link
>> them.
>>
>> 1- They can be fully included to all applications, using common
>> rte.app.mk file by default.
>>
>> 2- They can be explicitly linked to applications that use device
>> specific API.
>>
>> Currently option one is in use, this patch switches to the option two.
>>
>> Moves library linking to the application of Makefile that uses device
>> specific API.
>>
>> This prevent including these libraries into final applications that
>> don't use these device specific APIs.
> 
> That's an interesting point of view.
> What about the other libraries automatically linked in rte.app.mk?
> Could we make each application decide which library they want to be
> linked with?

Not need to.
For static library compilation, if the library in not within
--whole-archive flag, linker will get only used objects to final binary.
No harm on providing all libraries for that case.

For shared library compilation, PMDs are not linked against binary. And
other libraries can be added without problem because of "--as-needed"
flag, again linker will take care of unused libs.

But for example bonding pmd, for shared compilation, linked against all
applications, it is linked even against helloworld sample application:

$ ldd examples/helloworld/build/helloworld | grep bond
        librte_pmd_bond.so.1.1 =>
/root/dpdk/build/lib/librte_pmd_bond.so.1.1 (0x00007fa56da9a000)


I recognized that the comment in commit log is not exactly true, this is
not related to static compilation and including pmd into final binary,
that will always happen for a pmd in static build.

This is about making PMD a dependency to all applications or to the
applications that use it, for shared library compilation.




More information about the dev mailing list