From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org, Panu Matilainen <pmatilai@redhat.com>,
Christian Ehrhardt <christian.ehrhardt@canonical.com>
Subject: Re: [dpdk-dev] [PATCH v3 3/6] mk: sort libraries when linking, move pmd libs to higher level
Date: Mon, 13 Jun 2016 11:04:51 +0100 [thread overview]
Message-ID: <575E8543.2080504@intel.com> (raw)
In-Reply-To: <3213594.AWeSi4j5H8@xps13>
On 6/13/2016 10:29 AM, Thomas Monjalon wrote:
> 2016-06-10 19:32, Ferruh Yigit:
>> As stated in the comment:
>> Order is important: from higher level to lower level
>>
>> This is an attempt to make the layering order better respected.
>>
>> Limit scope of --whole-archive to pmd libraries
>
> Compared to the link order in the v2, you did two things:
> 1/ move PMDs to the first position
> 2/ restrict --whole-archive to PMDs only
>
> Having the PMDs first, helps the linker to get all the PMD dependencies
> in the static binary. Thus it seems we do not need --whole-archive
> for the PMD dependencies (ethdev, mbuf, etc).
> But, if an external PMD is loaded via dlopen, it is possible that it
> needs a symbol which was not used by the internal PMDs. So it will not
> be found in the statically linked binary.
> Let's take another example: if we disable the internal PMDs with their
> config options from the static build, and we decide to build them
> separately as DSOs. We won't be able to load them as plugins because
> they depend on symbols which won't be found in the static binary.
So you want to keep all objects in final binary (used or unused) because
of the possibility that any plugin may use them.
But what is the list to include here, whole dpdk?, -since we may not
know what API will plugin call.
What I am confused is --whole-archive only used when dpdk compiled as
static, if dpdk compiled as shared, each PMD should have proper
dependencies [1], and if external PMD compiled properly there shouldn't
be a problem. So do we have a case that dpdk compiled statically into
final binary but we still want to load some plugins dynamically?
>
> To make it short, the PMDs must be considered as plugins. Therefore, we
> must not rely on their availability to link the required symbols in
> a static binary.
> To make sure the plugin loading will be always well achieved, we must
> link the static PMDs at the last position.
I think this is not the issue of linking PMD's first or last, but
expanding --whole-archive to cover other libraries other than PMDs.
>
> If you agree, I vote for the v2 of this patchset.
If this is breaking something and best way to fix is not in external PMD
but in here, please feel free to go with v2.
[1] Like all has mbuf.so dependency:
# ldd build/lib/librte_pmd_ring.so
linux-vdso.so.1 (0x00007ffe3d78a000)
librte_eal.so.2.1 => not found
librte_ring.so.1.1 => not found
librte_mbuf.so.2.1 => not found
libethdev.so.4.1 => not found
librte_kvargs.so.1.1 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007f8ab5ae1000)
/lib64/ld-linux-x86-64.so.2 (0x0000556616488000)
# ldd build/lib/librte_pmd_af_packet.so
linux-vdso.so.1 (0x00007ffcb0572000)
librte_mbuf.so.2.1 => not found
libethdev.so.4.1 => not found
librte_kvargs.so.1.1 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007f7fbd4aa000)
/lib64/ld-linux-x86-64.so.2 (0x00005604556d2000)
# ldd build/lib/librte_pmd_null.so
linux-vdso.so.1 (0x00007ffdf08cf000)
librte_mbuf.so.2.1 => not found
libethdev.so.4.1 => not found
librte_kvargs.so.1.1 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007fca6fbfc000)
/lib64/ld-linux-x86-64.so.2 (0x000055fe7dd4a000)
Thanks,
ferruh
next prev parent reply other threads:[~2016-06-13 10:04 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 15:38 [dpdk-dev] Underlinked libs and overlinked applications - an issue? Christian Ehrhardt
2016-05-19 18:17 ` Thomas Monjalon
2016-05-20 11:01 ` Panu Matilainen
2016-05-20 12:41 ` Christian Ehrhardt
2016-05-20 16:43 ` Christian Ehrhardt
2016-05-20 16:50 ` [dpdk-dev] [PATCH] mk: fix underlinking issues of most librte libraries Christian Ehrhardt
2016-05-20 17:08 ` Thomas Monjalon
2016-05-24 9:56 ` Panu Matilainen
2016-05-24 10:11 ` Christian Ehrhardt
2016-05-26 13:13 ` Ferruh Yigit
2016-05-27 5:59 ` Panu Matilainen
2016-05-27 16:15 ` Ferruh Yigit
2016-05-27 16:48 ` [dpdk-dev] [PATCH 1/2] mk: prevent overlinking in applications Ferruh Yigit
2016-05-27 16:48 ` [dpdk-dev] [PATCH 2/2] mk: reduce scope of whole-archive to pmd libraries Ferruh Yigit
2016-06-10 9:03 ` Thomas Monjalon
2016-06-10 9:57 ` Ferruh Yigit
2016-06-10 10:18 ` Thomas Monjalon
2016-06-10 11:06 ` Ferruh Yigit
2016-06-10 12:21 ` Thomas Monjalon
2016-06-10 13:35 ` Ferruh Yigit
2016-06-09 10:10 ` [dpdk-dev] [PATCH 1/2] mk: prevent overlinking in applications Thomas Monjalon
2016-06-09 13:05 ` Ferruh Yigit
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 0/6] reduce " Thomas Monjalon
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 1/6] mk: sort drivers in static application link list Thomas Monjalon
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 2/6] mk: fix driver dependencies order for static application Thomas Monjalon
2016-06-10 14:49 ` Ferruh Yigit
2016-06-10 14:54 ` Thomas Monjalon
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 3/6] mk: remove library grouping during application linking Thomas Monjalon
2016-06-10 14:54 ` Ferruh Yigit
2016-06-10 15:14 ` Thomas Monjalon
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 4/6] mk: prevent overlinking in applications Thomas Monjalon
2016-06-10 14:56 ` Ferruh Yigit
2016-06-10 15:15 ` Thomas Monjalon
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 5/6] mk: sort libraries in level order when linking Thomas Monjalon
2016-06-10 13:19 ` [dpdk-dev] [PATCH v2 6/6] mk: reduce scope of whole-archive static linking Thomas Monjalon
2016-06-10 15:03 ` Ferruh Yigit
2016-06-10 15:18 ` Thomas Monjalon
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 0/6] reduce overlinking in applications Ferruh Yigit
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 1/6] mk: sort drivers in static application link list Ferruh Yigit
2016-06-10 19:38 ` Wiles, Keith
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 2/6] mk: fix driver dependencies order for static application Ferruh Yigit
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 3/6] mk: sort libraries when linking, move pmd libs to higher level Ferruh Yigit
2016-06-13 9:29 ` Thomas Monjalon
2016-06-13 10:04 ` Ferruh Yigit [this message]
2016-06-13 10:21 ` Thomas Monjalon
2016-06-13 10:29 ` Ferruh Yigit
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 4/6] mk: sort libraries when linking, move external libs to lower level Ferruh Yigit
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 5/6] mk: remove library grouping during application linking Ferruh Yigit
2016-06-10 18:32 ` [dpdk-dev] [PATCH v3 6/6] mk: prevent overlinking in applications Ferruh Yigit
2016-06-11 6:34 ` Thomas Monjalon
2016-06-13 9:05 ` Ferruh Yigit
2016-06-13 9:24 ` Christian Ehrhardt
2016-06-13 9:48 ` [dpdk-dev] [PATCH] mk: fix missing DEPDIRS to avoid libarary underlinking Christian Ehrhardt
2016-06-13 10:08 ` Thomas Monjalon
2016-06-13 10:20 ` Christian Ehrhardt
2016-06-13 11:06 ` [dpdk-dev] [PATCH v2 0/2] mk: fix more library underlinking Christian Ehrhardt
2016-06-13 11:06 ` [dpdk-dev] [PATCH v2 1/2] mk: fix missing vhost dependency to pthread to avoid libarary underlinking Christian Ehrhardt
2016-06-13 11:06 ` [dpdk-dev] [PATCH v2 2/2] mk: fix missing DEPDIRS " Christian Ehrhardt
2016-06-13 14:16 ` [dpdk-dev] [PATCH v2 0/2] mk: fix more library underlinking Thomas Monjalon
2016-06-13 14:14 ` [dpdk-dev] [PATCH v2 0/6] reduce overlinking in applications Thomas Monjalon
2016-06-07 8:23 ` [dpdk-dev] [PATCH] mk: fix underlinking issues of most librte libraries Thomas Monjalon
2016-06-07 9:25 ` Panu Matilainen
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=575E8543.2080504@intel.com \
--to=ferruh.yigit@intel.com \
--cc=christian.ehrhardt@canonical.com \
--cc=dev@dpdk.org \
--cc=pmatilai@redhat.com \
--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).