Re: [dpdk-dev] [PATCH v2] mk: fix external shared library dependencies of libraries

[Panu Matilainen <pmatilai@redhat.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 -