From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: fix acl library static linking
Date: Thu, 30 Jun 2016 16:58:35 +0100 [thread overview]
Message-ID: <42eb8687-b23e-cb6f-ba06-5e37ecdc7b3b@intel.com> (raw)
In-Reply-To: <1797205.YMNToqyLHv@xps13>
On 30/06/2016 16:28, Thomas Monjalon wrote:
> 2016-06-30 15:02, Sergio Gonzalez Monroy:
>> On 30/06/2016 13:44, Thomas Monjalon wrote:
>>> 2016-06-30 13:04, Sergio Gonzalez Monroy:
>>>> On 30/06/2016 12:38, Thomas Monjalon wrote:
>>>>> Does it need to be commented in rte.app.mk?
>>>>> The other libs are in whole-archive to support dlopen of drivers.
>>>>> But the problem here is not because of a driver use.
>>>> There seem to be a bunch of libraries under --whole-archive scope that
>>>> are not
>>>> PMDs, ie. cfgfile, cmdline...
>>>>
>>>> What is the criteria?
>>> The criteria is a bit vague. We must try to include only libs which can
>>> be used by a driver.
>>> cmdline should probably not be there.
>>> Does it make sense to use cfgfile in a driver? maybe yes.
>> So as it is, ACL autotest is broken when building static libs
>> (non-combined).
> I think the --whole-archive option must be set specifically for ACL
> with a comment explaining it is required because of weak functions:
>
> # librte_acl needs --whole-archive because of weak functions
> _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += --whole-archive -lrte_acl --no-whole-archive
Will do.
>> For combined libs we usually wrap libdpdk.a with --whole-archive, thus it is
>> not an issue.
>>
>> Just thinking a bit more about the 'dlopen of drivers' case you
>> mentioned before,
>> shouldn't the driver have proper dependencies and therefore need shared
>> DPDK libraries?
> It is possible to build a .so, without any DT_NEEDED entries, which will
> find the required symbols in the static linked binary.
Of course! All DPDK libraries were like that until recently.
That doesn't mean it was right though.
>> What does happen if binary/app and driver are built against different
>> library versions?
> Bad things :)
>
>> Where does it say that we do support this use case?
> It is maybe not written. But I know it is used by people wanting to load
> some PMD.so on demand while having the rest statically compiled.
> I agree it needs to be documented and probably better managed and tested.
>
Note that this only applies to apps built with DPDK build system.
In my opinion, I don't think we should be supporting such case.
But if we were to, we are probably just better of whole-archiving all
libraries into the
application. For example, what if there was a driver wanting to use ACL
or any
other DPDK lib not currently in the set of libs we "consider" should be
use by drivers?
Also, from what I have seen in the list, most folks do end up using
combined lib and
wrapping it with --whole-archive.
Sergio
next prev parent reply other threads:[~2016-06-30 15:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 11:10 Sergio Gonzalez Monroy
2016-06-30 11:38 ` Thomas Monjalon
2016-06-30 12:04 ` Sergio Gonzalez Monroy
2016-06-30 12:44 ` Thomas Monjalon
2016-06-30 14:02 ` Sergio Gonzalez Monroy
2016-06-30 15:24 ` Ananyev, Konstantin
2016-06-30 15:47 ` Thomas Monjalon
2016-06-30 15:28 ` Thomas Monjalon
2016-06-30 15:58 ` Sergio Gonzalez Monroy [this message]
2016-06-30 12:14 ` Ananyev, Konstantin
2016-06-30 16:01 ` [dpdk-dev] [PATCH v2] " Sergio Gonzalez Monroy
2016-06-30 16:10 ` Thomas Monjalon
2016-06-30 16:14 ` Sergio Gonzalez Monroy
2016-06-30 16:22 ` Thomas Monjalon
2016-07-01 8:05 ` Sergio Gonzalez Monroy
2016-07-01 10:05 ` Thomas Monjalon
2016-07-01 10:27 ` Sergio Gonzalez Monroy
2016-07-01 10:39 ` Thomas Monjalon
2016-06-30 16:11 ` [dpdk-dev] [PATCH v3] " Sergio Gonzalez Monroy
2016-07-01 14:38 ` [dpdk-dev] [PATCH v4 1/2] mk: allow duplicate linker flags in libraries list Sergio Gonzalez Monroy
2016-07-01 14:38 ` [dpdk-dev] [PATCH v4 2/2] mk: fix acl library static linking Sergio Gonzalez Monroy
2016-07-01 14:45 ` 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=42eb8687-b23e-cb6f-ba06-5e37ecdc7b3b@intel.com \
--to=sergio.gonzalez.monroy@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).