From: Panu Matilainen <pmatilai@redhat.com>
To: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] mk: fix external shared library dependencies of libraries
Date: Wed, 9 Dec 2015 14:09:23 +0200 [thread overview]
Message-ID: <566819F3.8030501@redhat.com> (raw)
In-Reply-To: <56670516.7050701@intel.com>
On 12/08/2015 06:28 PM, Sergio Gonzalez Monroy wrote:
> On 08/12/2015 11:47, Panu Matilainen wrote:
>> Similar to commit 5f9115e58cc6f304ff4ade694cf5823d32887d1a etc, but
>> for libraries. Clean up librte_vhost CFLAGS/LDFLAGS/LDLIBS confusion
>> while at it.
>>
>> Requiring applications to know about library internal details like
>> dependencies to external helper libraries is a limitation of
>> static linkage, shared libraries should always know their own
>> dependencies for sane operation.
>>
>> Linking with the combined library (whether shared or not) still
>> requires knowing the internal dependencies, and intra-dpdk
>> dependencies are also not currently recorded.
>>
>> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>> ---
>>
>> v2:
>> - clean up librte_vhost CFLAGS/LDFLAGS/LDLIBS confusion while at it
>>
>>
> Hi Panu,
>
> Patch itself looks good but there is a small side effect on BSD that
> results
> in app/test not linking because of missing -lm.
> Linuxapp links with -lm by default (EXECENV_LDLIBS), but BSD does not.
Oh, those LIBRTE_SCHED entries were in a different if-block from the
others...
Hmm, interesting. Without this patch, on Linux -lm gets added twice
which actually causes a build failure on Fedora rawhide (related to some
libmvec related changes it seems).
> Should we just add -lm to EXECENV_LDLIBS for BSD too instead of
> adding it on each app/example that uses librte_sched ?
Linking should be based on usage, not convenience or such... but there's
no explanation why -lm is added everywhere in Linux:
commit 6da94b7a92d9706c1a4fb23a9cf54f49e6019af2
Author: Intel <intel.com>
Date: Wed Sep 18 12:00:00 2013 +0200
mk: link with libm
Signed-off-by: Intel
Certainly librte_sched should link to -lm and in static builds, all its
users, but beyond that I suppose it needs closer investigation of what
(if anything else) actually needs it.
I think we better leave it alone for 2.2, but the librte_vhost part
should be safe. I can send another version with just that if it has a
chance to make it to 2.2, otherwise lets postpone it to 2.3.
- Panu -
- Panu -
- Panu -
next prev parent reply other threads:[~2015-12-09 12:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-08 11:47 [PATCH v2] mk: fix external shared library dependencies of libraries Panu Matilainen
2015-12-08 16:28 ` Sergio Gonzalez Monroy
2015-12-09 12:09 ` Panu Matilainen [this message]
2016-03-10 13:15 ` [PATCH v3 0/3] mk: add DT_NEEDED entries for external library deps Panu Matilainen
2016-03-10 13:15 ` [PATCH v3 1/3] mk: clear up libm and librt linkage confusion Panu Matilainen
2016-03-14 16:44 ` Ferruh Yigit
2016-03-15 6:24 ` Panu Matilainen
2016-03-10 13:16 ` [PATCH v3 2/3] mk: add DT_NEEDED entries for librte_vhost external dependencies Panu Matilainen
2016-03-10 13:16 ` [PATCH v3 3/3] mk: add DT_NEEDED entries for librte_eal " Panu Matilainen
2016-03-13 19:28 ` [PATCH v3 0/3] mk: add DT_NEEDED entries for external library deps 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=566819F3.8030501@redhat.com \
--to=pmatilai@redhat.com \
--cc=dev@dpdk.org \
--cc=sergio.gonzalez.monroy@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.