From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] mk: move PMD libraries to applications
Date: Tue, 31 Jan 2017 14:36:17 +0000 [thread overview]
Message-ID: <22948d37-7448-c07a-33ca-87b2007847f9@intel.com> (raw)
In-Reply-To: <2710569.WpYSWQ2PKI@xps13>
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.
next prev parent reply other threads:[~2017-01-31 14:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 12:14 [dpdk-dev] [PATCH 1/2] app/testpmd: use LDLIBS in makefile Ferruh Yigit
2017-01-31 12:14 ` [dpdk-dev] [PATCH 2/2] mk: move PMD libraries to applications Ferruh Yigit
2017-01-31 14:16 ` Thomas Monjalon
2017-01-31 14:36 ` Ferruh Yigit [this message]
2017-01-31 15:04 ` [dpdk-dev] [PATCH v2 1/2] app/testpmd: use LDLIBS in makefile Ferruh Yigit
2017-01-31 15:04 ` [dpdk-dev] [PATCH v2 2/2] mk: move PMD libraries to applications Ferruh Yigit
2017-02-10 10:04 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22948d37-7448-c07a-33ca-87b2007847f9@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).