[dpdk-dev,1/2] mk: prevent overlinking in applications

  Replace --no-as-needed linker flag with --as-needed flag, which will
only link libraries directly called by application. This requires inter
library dependencies resolved correctly.

Not linking all libraries cause a compile error for lpcap and possible
to have other similar compiler errors, so increasing the scope of
--start-group argument.

cmdline_test application causes compile error because of cyclic
dependency between librte_eal <-> librte_mempool. A workaround added to
cmdline_test for compile error.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

---

This patch is on top of patch:
http://dpdk.org/dev/patchwork/patch/12987/
---
 app/cmdline_test/Makefile        | 1 +
 mk/exec-env/linuxapp/rte.vars.mk | 2 +-
 mk/rte.app.mk                    | 3 +--
 3 files changed, 3 insertions(+), 3 deletions(-)
  

Hi Ferruh,

2016-05-27 17:48, Ferruh Yigit:
> Replace --no-as-needed linker flag with --as-needed flag, which will
> only link libraries directly called by application. This requires inter
> library dependencies resolved correctly.
> 
> Not linking all libraries cause a compile error for lpcap and possible
> to have other similar compiler errors, so increasing the scope of
> --start-group argument.

What is the error?

> cmdline_test application causes compile error because of cyclic
> dependency between librte_eal <-> librte_mempool. A workaround added to
> cmdline_test for compile error.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

> --- a/app/cmdline_test/Makefile
> +++ b/app/cmdline_test/Makefile
> @@ -46,6 +46,7 @@ SRCS-y += commands.c
>  
>  CFLAGS += -O3
>  CFLAGS += $(WERROR_FLAGS)

A comment is required here to explain the workaround.

> +LDFLAGS += -no-as-needed

The option should be --no-as-needed.

> --- a/mk/exec-env/linuxapp/rte.vars.mk
> +++ b/mk/exec-env/linuxapp/rte.vars.mk
> @@ -46,7 +46,7 @@ EXECENV_CFLAGS  = -pthread
>  endif
>  
>  # Workaround lack of DT_NEEDED entry

This comment is obsolete now.

> -EXECENV_LDFLAGS = --no-as-needed
> +EXECENV_LDFLAGS = --as-needed

Why put this option for Linux only?
Shouldn't we restrict this option to app.mk only?

> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -58,6 +58,7 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
>  #
>  
>  _LDLIBS-y += --whole-archive
> +_LDLIBS-y += --start-group

--start-group must be used only to solve circular dependencies.
Ideally we should not use it. I think it's needed only because
of EAL logs using mempool (must be removed).
Why extending it?
I'm afraid we are masking some issues.

>  _LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR)    += -lrte_distributor
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER)        += -lrte_reorder
> @@ -111,8 +112,6 @@ _LDLIBS-y                                   += -lcrypto
>  endif
>  endif # !CONFIG_RTE_BUILD_SHARED_LIBS
>  
> -_LDLIBS-y += --start-group
> -
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_KVARGS)         += -lrte_kvargs
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF)           += -lrte_mbuf
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)        += -lrte_ip_frag
  

On 6/9/2016 11:10 AM, Thomas Monjalon wrote:
> Hi Ferruh,
> 
> 2016-05-27 17:48, Ferruh Yigit:
>> Replace --no-as-needed linker flag with --as-needed flag, which will
>> only link libraries directly called by application. This requires inter
>> library dependencies resolved correctly.
>>
>> Not linking all libraries cause a compile error for lpcap and possible
>> to have other similar compiler errors, so increasing the scope of
>> --start-group argument.
> 
> What is the error?
> 
This is with -as-needed flag, and static library compilation:

.../dpdk/build/lib/librte_pmd_pcap.a(rte_eth_pcap.o): In function
`eth_dev_stop':
rte_eth_pcap.c:(.text+0xcc1): undefined reference to `pcap_dump_close'
rte_eth_pcap.c:(.text+0xcd6): undefined reference to `pcap_close'
rte_eth_pcap.c:(.text+0xd19): undefined reference to `pcap_close'
rte_eth_pcap.c:(.text+0xd58): undefined reference to `pcap_close'
/root/development/dpdk/build/lib/librte_pmd_pcap.a(rte_eth_pcap.o): In
function `open_tx_pcap':
rte_eth_pcap.c:(.text+0x190b): undefined reference to `pcap_open_dead'
rte_eth_pcap.c:(.text+0x191b): undefined reference to `pcap_dump_open'
...

pcap pmd has libpcap calls, but while linking final application
(testpmd), linker is not able to find objects that has these.

The command line for compilation is:
gcc ... -o test ... -Wl,--whole-archive <dpdk libs> -Wl,-lpcap
-Wl,--start-group <more dpdk libs> -Wl,-lrte_pmd_pcap <more dpdk libs>
-Wl,--end-group -Wl,--no-whole-archive

-lpcap is provided, but since before -lrte_pmd_pcap, references not
resolved.

Previously, with "-no-as-needed" flag, all shared libraries linked
always, which was preventing compile error.


>> cmdline_test application causes compile error because of cyclic
>> dependency between librte_eal <-> librte_mempool. A workaround added to
>> cmdline_test for compile error.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
>> --- a/app/cmdline_test/Makefile
>> +++ b/app/cmdline_test/Makefile
>> @@ -46,6 +46,7 @@ SRCS-y += commands.c
>>  
>>  CFLAGS += -O3
>>  CFLAGS += $(WERROR_FLAGS)
> 
> A comment is required here to explain the workaround.
> 

Sure, I will add a comment and send a new version of the patch.

>> +LDFLAGS += -no-as-needed
> 
> The option should be --no-as-needed.
Right

> 
>> --- a/mk/exec-env/linuxapp/rte.vars.mk
>> +++ b/mk/exec-env/linuxapp/rte.vars.mk
>> @@ -46,7 +46,7 @@ EXECENV_CFLAGS  = -pthread
>>  endif
>>  
>>  # Workaround lack of DT_NEEDED entry
> 
> This comment is obsolete now.
Will remove.

> 
>> -EXECENV_LDFLAGS = --no-as-needed
>> +EXECENV_LDFLAGS = --as-needed
> 
> Why put this option for Linux only?
When this option not defined at all, different compilers behave
different, some has --as-needed as default and cause compilation issues,
I guess that is why for Linux --no-as-needed is forces. I assume BSD
compilers by default use --no-as-needed, so we don't have any
compilation problem.
And it looks like there is no specific reason to not force BSD to
--as-needed, I will test it.

> Shouldn't we restrict this option to app.mk only?
Having --no-needed flag only for app should be OK. Let me test first,
and as a result should we move this to app.mk?

> 
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -58,6 +58,7 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
>>  #
>>  
>>  _LDLIBS-y += --whole-archive
>> +_LDLIBS-y += --start-group
> 
> --start-group must be used only to solve circular dependencies.
> Ideally we should not use it. I think it's needed only because
> of EAL logs using mempool (must be removed).
No, this is not the reason, please check above lpcap compile error, that
is the reason of this update.

> Why extending it?
> I'm afraid we are masking some issues.
But if we have a convention to add external libraries after dpdk
libraries, that also should solve this issue, but that is more update
than just updating --start-group.

> 
>>  _LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR)    += -lrte_distributor
>>  _LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER)        += -lrte_reorder
>> @@ -111,8 +112,6 @@ _LDLIBS-y                                   += -lcrypto
>>  endif
>>  endif # !CONFIG_RTE_BUILD_SHARED_LIBS
>>  
>> -_LDLIBS-y += --start-group
>> -
>>  _LDLIBS-$(CONFIG_RTE_LIBRTE_KVARGS)         += -lrte_kvargs
>>  _LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF)           += -lrte_mbuf
>>  _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)        += -lrte_ip_frag
>
  

This is a respin of the ideas of Christian and Ferruh to limit
the static application size or dynamic links to shared libraries.

It also brings some clean-up in rte.app.mk.

Ferruh Yigit (2):
  mk: prevent overlinking in applications
  mk: reduce scope of whole-archive static linking

Thomas Monjalon (4):
  mk: sort drivers in static application link list
  mk: fix driver dependencies order for static application
  mk: remove library grouping during application linking
  mk: sort libraries in level order when linking

 mk/exec-env/linuxapp/rte.vars.mk |   3 -
 mk/rte.app.mk                    | 134 ++++++++++++++++-----------------------
 2 files changed, 55 insertions(+), 82 deletions(-)
  

This patch set updates application linking, main motivation is to reduce
overlinking in application, also removes library grouping by re-ordering
libraries and for static compilation reduces whole library linking to PMD
libs.

There is a workaround because of librte_eal <-> librte_mempool cyclic
dependency in rte.app.mk, which can be removed when issue solved.

It also brings some clean-up in rte.app.mk.

Ferruh Yigit (3):
  mk: sort libraries when linking, move pmd libs to higher level
  mk: sort libraries when linking, move external libs to lower level
  mk: prevent overlinking in applications

Thomas Monjalon (3):
  mk: sort drivers in static application link list
  mk: fix driver dependencies order for static application
  mk: remove library grouping during application linking

 mk/exec-env/linuxapp/rte.vars.mk |   3 -
 mk/rte.app.mk                    | 152 +++++++++++++++++----------------------
 2 files changed, 66 insertions(+), 89 deletions(-)
  

2016-06-10 15:19, Thomas Monjalon:
> This is a respin of the ideas of Christian and Ferruh to limit
> the static application size or dynamic links to shared libraries.
> 
> It also brings some clean-up in rte.app.mk.
> 
> Ferruh Yigit (2):
>   mk: prevent overlinking in applications
>   mk: reduce scope of whole-archive static linking
> 
> Thomas Monjalon (4):
>   mk: sort drivers in static application link list
>   mk: fix driver dependencies order for static application
>   mk: remove library grouping during application linking
>   mk: sort libraries in level order when linking

Applied