* [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
2015-04-08 18:26 ` Stephen Hemminger
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script Sergio Gonzalez Monroy
` (3 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
To: dev
Currently, the target/rules to build combined libraries is different
than the one to build individual libraries.
By removing the combined library option as a build configuration option
we simplify the build pocess by having a single point for linking/archiving
libraries in DPDK.
This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
removes the makefiles associated with building a combined library.
The CONFIG_RTE_LIBNAME config option is kept as it will be use to
always generate a linker script that acts as a single combined library.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
config/common_bsdapp | 3 +-
config/common_linuxapp | 3 +-
lib/Makefile | 1 -
mk/rte.app.mk | 12 ------
mk/rte.lib.mk | 35 -----------------
mk/rte.sdkbuild.mk | 3 --
mk/rte.sharelib.mk | 101 -------------------------------------------------
mk/rte.vars.mk | 4 --
8 files changed, 2 insertions(+), 160 deletions(-)
delete mode 100644 mk/rte.sharelib.mk
diff --git a/config/common_bsdapp b/config/common_bsdapp
index a8ba484..ab6be97 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
+# Combined library name
#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
CONFIG_RTE_LIBNAME=intel_dpdk
#
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0b25f34..1ae4304 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
+# Combined library name
#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
CONFIG_RTE_LIBNAME="intel_dpdk"
#
diff --git a/lib/Makefile b/lib/Makefile
index d94355d..c34cf2f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -77,5 +77,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 56886dc..e8630b6 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -61,12 +61,6 @@ ifeq ($(NO_AUTOLIBS),)
LDLIBS += --whole-archive
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-LDLIBS += -l$(RTE_LIBNAME)
-endif
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
LDLIBS += -lrte_distributor
endif
@@ -137,8 +131,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
LDLIBS += -lrte_vhost
endif
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
LDLIBS += -lpcap
endif
@@ -153,8 +145,6 @@ endif
LDLIBS += --start-group
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
LDLIBS += -lrte_kvargs
endif
@@ -253,8 +243,6 @@ endif
endif # plugins
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
LDLIBS += $(EXECENV_LDLIBS)
LDLIBS += --end-group
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 0d7482d..d96101a 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -87,24 +87,6 @@ O_TO_S_DO = @set -e; \
$(O_TO_S) && \
echo $(O_TO_S_CMD) > $(call exe2cmd,$(@))
-ifeq ($(RTE_BUILD_SHARED_LIB),n)
-O_TO_C = $(AR) crus $(LIB_ONE) $(OBJS-y)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)"," AR_C $(@)")
-O_TO_C_DO = @set -e; \
- $(lib_dir) \
- $(copy_obj)
-else
-O_TO_C = $(LD) -shared $(OBJS-y) -o $(LIB_ONE)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)"," LD_C $(@)")
-O_TO_C_DO = @set -e; \
- $(lib_dir) \
- $(copy_obj)
-endif
-
-copy_obj = cp -f $(OBJS-y) $(RTE_OUTPUT)/build/lib;
-lib_dir = [ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib;
-include .$(LIB).cmd
#
@@ -129,15 +111,6 @@ endif
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_S_DO))
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
else
$(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
@@ -153,14 +126,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_A_DO))
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
endif
#
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 3154457..2b24e74 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,9 +93,6 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
- @if [ $@ = lib -a $(RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
- fi
%_clean:
@echo "== Clean $*"
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
deleted file mode 100644
index de53558..0000000
--- a/mk/rte.sharelib.mk
+++ /dev/null
@@ -1,101 +0,0 @@
-# BSD LICENSE
-#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-# * Neither the name of Intel Corporation nor the names of its
-# contributors may be used to endorse or promote products derived
-# from this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-include $(RTE_SDK)/mk/internal/rte.build-pre.mk
-
-# VPATH contains at least SRCDIR
-VPATH += $(SRCDIR)
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(RTE_BUILD_SHARED_LIB),y)
-LIB_ONE := lib$(RTE_LIBNAME).so
-else
-LIB_ONE := lib$(RTE_LIBNAME).a
-endif
-endif
-
-.PHONY:sharelib
-sharelib: $(LIB_ONE) FORCE
-
-OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)
-
-ifeq ($(LINK_USING_CC),1)
-# Override the definition of LD here, since we're linking with CC
-LD := $(CC) $(CPU_CFLAGS)
-O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-endif
-
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
-O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)")
-O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
-O_TO_S_DO = @set -e; \
- echo $(O_TO_S_DISP); \
- $(O_TO_S)
-
-O_TO_A = $(AR) crus $(RTE_OUTPUT)/lib/$(LIB_ONE) $(OBJS)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
-O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)"," LD $(@)")
-O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
-O_TO_A_DO = @set -e; \
- echo $(O_TO_A_DISP); \
- $(O_TO_A)
-#
-# Archive objects to share library
-#
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(RTE_BUILD_SHARED_LIB),y)
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_S_DO)
-else
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_A_DO)
-endif
-endif
-
-#
-# Clean all generated files
-#
-.PHONY: clean
-clean: _postclean
-
-.PHONY: doclean
-doclean:
- $(Q)rm -rf $(LIB_ONE)
-
-.PHONY: FORCE
-FORCE:
diff --git a/mk/rte.vars.mk b/mk/rte.vars.mk
index d2f01b6..fd06175 100644
--- a/mk/rte.vars.mk
+++ b/mk/rte.vars.mk
@@ -67,10 +67,6 @@ ifneq ($(BUILDING_RTE_SDK),)
ifeq ($(RTE_BUILD_SHARED_LIB),)
RTE_BUILD_SHARED_LIB := n
endif
- RTE_BUILD_COMBINE_LIBS := $(CONFIG_RTE_BUILD_COMBINE_LIBS:"%"=%)
- ifeq ($(RTE_BUILD_COMBINE_LIBS),)
- RTE_BUILD_COMBINE_LIBS := n
- endif
endif
RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
--
1.9.3
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
@ 2015-04-08 18:26 ` Stephen Hemminger
2015-04-09 8:33 ` Gonzalez Monroy, Sergio
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Hemminger @ 2015-04-08 18:26 UTC (permalink / raw)
To: Sergio Gonzalez Monroy; +Cc: dev
On Wed, 8 Apr 2015 16:07:21 +0100
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> Currently, the target/rules to build combined libraries is different
> than the one to build individual libraries.
>
> By removing the combined library option as a build configuration option
> we simplify the build pocess by having a single point for linking/archiving
> libraries in DPDK.
>
> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> removes the makefiles associated with building a combined library.
>
> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> always generate a linker script that acts as a single combined library.
>
> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
No. We use combined library and it greatly simplfies the application
linking process.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-08 18:26 ` Stephen Hemminger
@ 2015-04-09 8:33 ` Gonzalez Monroy, Sergio
2015-04-09 9:06 ` Avi Kivity
0 siblings, 1 reply; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-09 8:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On 08/04/2015 19:26, Stephen Hemminger wrote:
> On Wed, 8 Apr 2015 16:07:21 +0100
> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>
>> Currently, the target/rules to build combined libraries is different
>> than the one to build individual libraries.
>>
>> By removing the combined library option as a build configuration option
>> we simplify the build pocess by having a single point for linking/archiving
>> libraries in DPDK.
>>
>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>> removes the makefiles associated with building a combined library.
>>
>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>> always generate a linker script that acts as a single combined library.
>>
>> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> No. We use combined library and it greatly simplfies the application
> linking process.
>
After all the opposition this patch had in v2, I did explain the current
issues
(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this
was the agreed solution.
As I mention in the cover letter (also see patch 2/5), building DPDK
(after applying this patch series) will always generate a very simple
linker script that behaves as a combined library.
I encourage you to apply this patch series and try to build your app
(which links against combined lib).
Your app should build without problem unless I messed up somewhere and
it needs fixing.
Sergio
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 8:33 ` Gonzalez Monroy, Sergio
@ 2015-04-09 9:06 ` Avi Kivity
2015-04-09 9:42 ` Gonzalez Monroy, Sergio
2015-04-09 11:19 ` Neil Horman
0 siblings, 2 replies; 18+ messages in thread
From: Avi Kivity @ 2015-04-09 9:06 UTC (permalink / raw)
To: Gonzalez Monroy, Sergio, Stephen Hemminger; +Cc: dev
On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> On 08/04/2015 19:26, Stephen Hemminger wrote:
>> On Wed, 8 Apr 2015 16:07:21 +0100
>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>
>>> Currently, the target/rules to build combined libraries is different
>>> than the one to build individual libraries.
>>>
>>> By removing the combined library option as a build configuration option
>>> we simplify the build pocess by having a single point for
>>> linking/archiving
>>> libraries in DPDK.
>>>
>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>> removes the makefiles associated with building a combined library.
>>>
>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>> always generate a linker script that acts as a single combined library.
>>>
>>> Signed-off-by: Sergio Gonzalez Monroy
>>> <sergio.gonzalez.monroy@intel.com>
>> No. We use combined library and it greatly simplfies the application
>> linking process.
>>
> After all the opposition this patch had in v2, I did explain the
> current issues
> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this
> was the agreed solution.
>
> As I mention in the cover letter (also see patch 2/5), building DPDK
> (after applying this patch series) will always generate a very simple
> linker script that behaves as a combined library.
> I encourage you to apply this patch series and try to build your app
> (which links against combined lib).
> Your app should build without problem unless I messed up somewhere and
> it needs fixing.
Is it possible to generate a pkgconfig file (dpdk.pc) that contains all
of the setting needed to compile and link with dpdk? That will greatly
simplify usage.
A linker script is just too esoteric.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 9:06 ` Avi Kivity
@ 2015-04-09 9:42 ` Gonzalez Monroy, Sergio
2015-04-09 11:19 ` Neil Horman
1 sibling, 0 replies; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-09 9:42 UTC (permalink / raw)
To: Avi Kivity; +Cc: dev
On 09/04/2015 10:06, Avi Kivity wrote:
>
>
> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>> On Wed, 8 Apr 2015 16:07:21 +0100
>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>
>>>> Currently, the target/rules to build combined libraries is different
>>>> than the one to build individual libraries.
>>>>
>>>> By removing the combined library option as a build configuration
>>>> option
>>>> we simplify the build pocess by having a single point for
>>>> linking/archiving
>>>> libraries in DPDK.
>>>>
>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option
>>>> and
>>>> removes the makefiles associated with building a combined library.
>>>>
>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>> always generate a linker script that acts as a single combined
>>>> library.
>>>>
>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>> <sergio.gonzalez.monroy@intel.com>
>>> No. We use combined library and it greatly simplfies the application
>>> linking process.
>>>
>> After all the opposition this patch had in v2, I did explain the
>> current issues
>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and
>> this was the agreed solution.
>>
>> As I mention in the cover letter (also see patch 2/5), building DPDK
>> (after applying this patch series) will always generate a very simple
>> linker script that behaves as a combined library.
>> I encourage you to apply this patch series and try to build your app
>> (which links against combined lib).
>> Your app should build without problem unless I messed up somewhere
>> and it needs fixing.
>
> Is it possible to generate a pkgconfig file (dpdk.pc) that contains
> all of the setting needed to compile and link with dpdk? That will
> greatly simplify usage.
>
> A linker script is just too esoteric.
>
>
That sounds very interesting.
I would be in favor of dropping the linker script for this solution if
everybody is happy with it.
Sergio
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 9:06 ` Avi Kivity
2015-04-09 9:42 ` Gonzalez Monroy, Sergio
@ 2015-04-09 11:19 ` Neil Horman
2015-04-09 13:33 ` Thomas Monjalon
2015-04-09 17:00 ` Avi Kivity
1 sibling, 2 replies; 18+ messages in thread
From: Neil Horman @ 2015-04-09 11:19 UTC (permalink / raw)
To: Avi Kivity; +Cc: dev
On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>
>
> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> >On 08/04/2015 19:26, Stephen Hemminger wrote:
> >>On Wed, 8 Apr 2015 16:07:21 +0100
> >>Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> >>
> >>>Currently, the target/rules to build combined libraries is different
> >>>than the one to build individual libraries.
> >>>
> >>>By removing the combined library option as a build configuration option
> >>>we simplify the build pocess by having a single point for
> >>>linking/archiving
> >>>libraries in DPDK.
> >>>
> >>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> >>>removes the makefiles associated with building a combined library.
> >>>
> >>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> >>>always generate a linker script that acts as a single combined library.
> >>>
> >>>Signed-off-by: Sergio Gonzalez Monroy
> >>><sergio.gonzalez.monroy@intel.com>
> >>No. We use combined library and it greatly simplfies the application
> >>linking process.
> >>
> >After all the opposition this patch had in v2, I did explain the current
> >issues
> >(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> >the agreed solution.
> >
> >As I mention in the cover letter (also see patch 2/5), building DPDK
> >(after applying this patch series) will always generate a very simple
> >linker script that behaves as a combined library.
> >I encourage you to apply this patch series and try to build your app
> >(which links against combined lib).
> >Your app should build without problem unless I messed up somewhere and it
> >needs fixing.
>
> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> the setting needed to compile and link with dpdk? That will greatly
> simplify usage.
>
> A linker script is just too esoteric.
>
Why esoteric? We're not talking about a linker script in the sense of a binary
layout file, we're talking about a prewritten/generated libdpdk_core.so that
contains linker directives to include the appropriate libraries. You link it
just like you do any other library, but it lets you ignore how they are broken
up.
We could certainly do a pkg-config file, but I don't think thats any more
adventageous than this solution.
Neil
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 11:19 ` Neil Horman
@ 2015-04-09 13:33 ` Thomas Monjalon
2015-04-09 13:47 ` Gonzalez Monroy, Sergio
2015-04-09 17:00 ` Avi Kivity
1 sibling, 1 reply; 18+ messages in thread
From: Thomas Monjalon @ 2015-04-09 13:33 UTC (permalink / raw)
To: Neil Horman, Avi Kivity; +Cc: dev
2015-04-09 07:19, Neil Horman:
> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> > On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> > >On 08/04/2015 19:26, Stephen Hemminger wrote:
> > >>On Wed, 8 Apr 2015 16:07:21 +0100
> > >>Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> > >>
> > >>>Currently, the target/rules to build combined libraries is different
> > >>>than the one to build individual libraries.
> > >>>
> > >>>By removing the combined library option as a build configuration option
> > >>>we simplify the build pocess by having a single point for
> > >>>linking/archiving
> > >>>libraries in DPDK.
> > >>>
> > >>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> > >>>removes the makefiles associated with building a combined library.
> > >>>
> > >>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> > >>>always generate a linker script that acts as a single combined library.
> > >>>
> > >>>Signed-off-by: Sergio Gonzalez Monroy
> > >>><sergio.gonzalez.monroy@intel.com>
> > >>No. We use combined library and it greatly simplfies the application
> > >>linking process.
> > >>
> > >After all the opposition this patch had in v2, I did explain the current
> > >issues
> > >(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> > >the agreed solution.
> > >
> > >As I mention in the cover letter (also see patch 2/5), building DPDK
> > >(after applying this patch series) will always generate a very simple
> > >linker script that behaves as a combined library.
> > >I encourage you to apply this patch series and try to build your app
> > >(which links against combined lib).
> > >Your app should build without problem unless I messed up somewhere and it
> > >needs fixing.
> >
> > Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> > the setting needed to compile and link with dpdk? That will greatly
> > simplify usage.
> >
> > A linker script is just too esoteric.
> >
> Why esoteric? We're not talking about a linker script in the sense of a binary
> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> contains linker directives to include the appropriate libraries. You link it
> just like you do any other library, but it lets you ignore how they are broken
> up.
>
> We could certainly do a pkg-config file, but I don't think thats any more
> adventageous than this solution.
As already commented (http://dpdk.org/ml/archives/dev/2015-March/015367.html),
pkgconfig could be something useful in any case (single or multi-libraries).
Having a linker script to replace the single ("combined") library may be
convenient in some cases but do not replace pkgconfig.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 13:33 ` Thomas Monjalon
@ 2015-04-09 13:47 ` Gonzalez Monroy, Sergio
0 siblings, 0 replies; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-09 13:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On 09/04/2015 14:33, Thomas Monjalon wrote:
> 2015-04-09 07:19, Neil Horman:
>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>>> On Wed, 8 Apr 2015 16:07:21 +0100
>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>>>
>>>>>> Currently, the target/rules to build combined libraries is different
>>>>>> than the one to build individual libraries.
>>>>>>
>>>>>> By removing the combined library option as a build configuration option
>>>>>> we simplify the build pocess by having a single point for
>>>>>> linking/archiving
>>>>>> libraries in DPDK.
>>>>>>
>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>>>>> removes the makefiles associated with building a combined library.
>>>>>>
>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>>>> always generate a linker script that acts as a single combined library.
>>>>>>
>>>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>>>> <sergio.gonzalez.monroy@intel.com>
>>>>> No. We use combined library and it greatly simplfies the application
>>>>> linking process.
>>>>>
>>>> After all the opposition this patch had in v2, I did explain the current
>>>> issues
>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
>>>> the agreed solution.
>>>>
>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
>>>> (after applying this patch series) will always generate a very simple
>>>> linker script that behaves as a combined library.
>>>> I encourage you to apply this patch series and try to build your app
>>>> (which links against combined lib).
>>>> Your app should build without problem unless I messed up somewhere and it
>>>> needs fixing.
>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
>>> the setting needed to compile and link with dpdk? That will greatly
>>> simplify usage.
>>>
>>> A linker script is just too esoteric.
>>>
>> Why esoteric? We're not talking about a linker script in the sense of a binary
>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
>> contains linker directives to include the appropriate libraries. You link it
>> just like you do any other library, but it lets you ignore how they are broken
>> up.
>>
>> We could certainly do a pkg-config file, but I don't think thats any more
>> adventageous than this solution.
> As already commented (http://dpdk.org/ml/archives/dev/2015-March/015367.html),
I misunderstood the pkgconfig reference in your previous comment.
It seems even more trivial to generate the 'combined' linker script lib
having a pkg-config file.
We could simplify much of the rte.app.mk by using a pkg-config file.
Sergio
> pkgconfig could be something useful in any case (single or multi-libraries).
> Having a linker script to replace the single ("combined") library may be
> convenient in some cases but do not replace pkgconfig.
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 11:19 ` Neil Horman
2015-04-09 13:33 ` Thomas Monjalon
@ 2015-04-09 17:00 ` Avi Kivity
2015-04-09 20:34 ` Neil Horman
1 sibling, 1 reply; 18+ messages in thread
From: Avi Kivity @ 2015-04-09 17:00 UTC (permalink / raw)
To: Neil Horman; +Cc: dev
On 04/09/2015 02:19 PM, Neil Horman wrote:
> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>
>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>> On Wed, 8 Apr 2015 16:07:21 +0100
>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>>
>>>>> Currently, the target/rules to build combined libraries is different
>>>>> than the one to build individual libraries.
>>>>>
>>>>> By removing the combined library option as a build configuration option
>>>>> we simplify the build pocess by having a single point for
>>>>> linking/archiving
>>>>> libraries in DPDK.
>>>>>
>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>>>> removes the makefiles associated with building a combined library.
>>>>>
>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>>> always generate a linker script that acts as a single combined library.
>>>>>
>>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>>> <sergio.gonzalez.monroy@intel.com>
>>>> No. We use combined library and it greatly simplfies the application
>>>> linking process.
>>>>
>>> After all the opposition this patch had in v2, I did explain the current
>>> issues
>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
>>> the agreed solution.
>>>
>>> As I mention in the cover letter (also see patch 2/5), building DPDK
>>> (after applying this patch series) will always generate a very simple
>>> linker script that behaves as a combined library.
>>> I encourage you to apply this patch series and try to build your app
>>> (which links against combined lib).
>>> Your app should build without problem unless I messed up somewhere and it
>>> needs fixing.
>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
>> the setting needed to compile and link with dpdk? That will greatly
>> simplify usage.
>>
>> A linker script is just too esoteric.
>>
> Why esoteric? We're not talking about a linker script in the sense of a binary
> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> contains linker directives to include the appropriate libraries. You link it
> just like you do any other library, but it lets you ignore how they are broken
> up.
You mean DT_NEEDED? That's great, but it shouldn't be called a linker
script.
> We could certainly do a pkg-config file, but I don't think thats any more
> adventageous than this solution.
It solves more problems -- cflags etc. Of course having the right
DT_NEEDED is a good thing regardless.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 17:00 ` Avi Kivity
@ 2015-04-09 20:34 ` Neil Horman
2015-04-13 9:52 ` Gonzalez Monroy, Sergio
0 siblings, 1 reply; 18+ messages in thread
From: Neil Horman @ 2015-04-09 20:34 UTC (permalink / raw)
To: Avi Kivity; +Cc: dev
On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
> On 04/09/2015 02:19 PM, Neil Horman wrote:
> >On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> >>
> >>On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> >>>On 08/04/2015 19:26, Stephen Hemminger wrote:
> >>>>On Wed, 8 Apr 2015 16:07:21 +0100
> >>>>Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> >>>>
> >>>>>Currently, the target/rules to build combined libraries is different
> >>>>>than the one to build individual libraries.
> >>>>>
> >>>>>By removing the combined library option as a build configuration option
> >>>>>we simplify the build pocess by having a single point for
> >>>>>linking/archiving
> >>>>>libraries in DPDK.
> >>>>>
> >>>>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> >>>>>removes the makefiles associated with building a combined library.
> >>>>>
> >>>>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> >>>>>always generate a linker script that acts as a single combined library.
> >>>>>
> >>>>>Signed-off-by: Sergio Gonzalez Monroy
> >>>>><sergio.gonzalez.monroy@intel.com>
> >>>>No. We use combined library and it greatly simplfies the application
> >>>>linking process.
> >>>>
> >>>After all the opposition this patch had in v2, I did explain the current
> >>>issues
> >>>(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> >>>the agreed solution.
> >>>
> >>>As I mention in the cover letter (also see patch 2/5), building DPDK
> >>>(after applying this patch series) will always generate a very simple
> >>>linker script that behaves as a combined library.
> >>>I encourage you to apply this patch series and try to build your app
> >>>(which links against combined lib).
> >>>Your app should build without problem unless I messed up somewhere and it
> >>>needs fixing.
> >>Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> >>the setting needed to compile and link with dpdk? That will greatly
> >>simplify usage.
> >>
> >>A linker script is just too esoteric.
> >>
> >Why esoteric? We're not talking about a linker script in the sense of a binary
> >layout file, we're talking about a prewritten/generated libdpdk_core.so that
> >contains linker directives to include the appropriate libraries. You link it
> >just like you do any other library, but it lets you ignore how they are broken
> >up.
>
> You mean DT_NEEDED? That's great, but it shouldn't be called a linker
> script.
>
no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
sergio wrote is.
> >We could certainly do a pkg-config file, but I don't think thats any more
> >adventageous than this solution.
>
> It solves more problems -- cflags etc. Of course having the right DT_NEEDED
> is a good thing regardless.
>
Thats a good point, pkgconfig doesn't provide that additionally. Perhaps having
both is the best solution. As for the DT_NEEDED issues, the earlier threads
ennumerated all the problems that were being found with the way the libraries
were organized (circular dependencies).
Neil
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-09 20:34 ` Neil Horman
@ 2015-04-13 9:52 ` Gonzalez Monroy, Sergio
2015-04-13 11:04 ` Thomas Monjalon
0 siblings, 1 reply; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-13 9:52 UTC (permalink / raw)
To: Neil Horman; +Cc: dev
On 09/04/2015 21:34, Neil Horman wrote:
> On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
>> On 04/09/2015 02:19 PM, Neil Horman wrote:
>>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>>>> On Wed, 8 Apr 2015 16:07:21 +0100
>>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>>>>
>>>>>>> Currently, the target/rules to build combined libraries is different
>>>>>>> than the one to build individual libraries.
>>>>>>>
>>>>>>> By removing the combined library option as a build configuration option
>>>>>>> we simplify the build pocess by having a single point for
>>>>>>> linking/archiving
>>>>>>> libraries in DPDK.
>>>>>>>
>>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>>>>>> removes the makefiles associated with building a combined library.
>>>>>>>
>>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>>>>> always generate a linker script that acts as a single combined library.
>>>>>>>
>>>>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>>>>> <sergio.gonzalez.monroy@intel.com>
>>>>>> No. We use combined library and it greatly simplfies the application
>>>>>> linking process.
>>>>>>
>>>>> After all the opposition this patch had in v2, I did explain the current
>>>>> issues
>>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
>>>>> the agreed solution.
>>>>>
>>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
>>>>> (after applying this patch series) will always generate a very simple
>>>>> linker script that behaves as a combined library.
>>>>> I encourage you to apply this patch series and try to build your app
>>>>> (which links against combined lib).
>>>>> Your app should build without problem unless I messed up somewhere and it
>>>>> needs fixing.
>>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
>>>> the setting needed to compile and link with dpdk? That will greatly
>>>> simplify usage.
>>>>
>>>> A linker script is just too esoteric.
>>>>
>>> Why esoteric? We're not talking about a linker script in the sense of a binary
>>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
>>> contains linker directives to include the appropriate libraries. You link it
>>> just like you do any other library, but it lets you ignore how they are broken
>>> up.
>> You mean DT_NEEDED? That's great, but it shouldn't be called a linker
>> script.
>>
> no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
> sergio wrote is.
>
>>> We could certainly do a pkg-config file, but I don't think thats any more
>>> adventageous than this solution.
>> It solves more problems -- cflags etc. Of course having the right DT_NEEDED
>> is a good thing regardless.
>>
> Thats a good point, pkgconfig doesn't provide that additionally. Perhaps having
> both is the best solution. As for the DT_NEEDED issues, the earlier threads
> ennumerated all the problems that were being found with the way the libraries
> were organized (circular dependencies).
>
> Neil
I am not entirely sure of the conclusion of this thread.
Are we happy with the current linker script solution as a replacement of
the combined lib?
Do we want to provide pkg-config file in addition or instead of linker
script?
I think I will split the series as there seems to be no objections to
the patches related to DT_NEEDED entries.
I'll post a series for DT_NEEDED entries and another series for dealing
with the combined lib (once we get to an agreement).
Does it sound reasonable?
Sergio
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-13 9:52 ` Gonzalez Monroy, Sergio
@ 2015-04-13 11:04 ` Thomas Monjalon
2015-04-13 11:23 ` Neil Horman
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Monjalon @ 2015-04-13 11:04 UTC (permalink / raw)
To: Gonzalez Monroy, Sergio; +Cc: dev
2015-04-13 10:52, Gonzalez Monroy, Sergio:
> On 09/04/2015 21:34, Neil Horman wrote:
> > On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
> >> On 04/09/2015 02:19 PM, Neil Horman wrote:
> >>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> >>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> >>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
> >>>>>> On Wed, 8 Apr 2015 16:07:21 +0100
> >>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> >>>>>>
> >>>>>>> Currently, the target/rules to build combined libraries is different
> >>>>>>> than the one to build individual libraries.
> >>>>>>>
> >>>>>>> By removing the combined library option as a build configuration option
> >>>>>>> we simplify the build pocess by having a single point for
> >>>>>>> linking/archiving
> >>>>>>> libraries in DPDK.
> >>>>>>>
> >>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> >>>>>>> removes the makefiles associated with building a combined library.
> >>>>>>>
> >>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> >>>>>>> always generate a linker script that acts as a single combined library.
> >>>>>>>
> >>>>>>> Signed-off-by: Sergio Gonzalez Monroy
> >>>>>>> <sergio.gonzalez.monroy@intel.com>
> >>>>>> No. We use combined library and it greatly simplfies the application
> >>>>>> linking process.
> >>>>>>
> >>>>> After all the opposition this patch had in v2, I did explain the current
> >>>>> issues
> >>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> >>>>> the agreed solution.
> >>>>>
> >>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
> >>>>> (after applying this patch series) will always generate a very simple
> >>>>> linker script that behaves as a combined library.
> >>>>> I encourage you to apply this patch series and try to build your app
> >>>>> (which links against combined lib).
> >>>>> Your app should build without problem unless I messed up somewhere and it
> >>>>> needs fixing.
> >>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> >>>> the setting needed to compile and link with dpdk? That will greatly
> >>>> simplify usage.
> >>>>
> >>>> A linker script is just too esoteric.
> >>>>
> >>> Why esoteric? We're not talking about a linker script in the sense of a binary
> >>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> >>> contains linker directives to include the appropriate libraries. You link it
> >>> just like you do any other library, but it lets you ignore how they are broken
> >>> up.
> >> You mean DT_NEEDED? That's great, but it shouldn't be called a linker
> >> script.
> >>
> > no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
> > sergio wrote is.
> >
> >>> We could certainly do a pkg-config file, but I don't think thats any more
> >>> adventageous than this solution.
> >> It solves more problems -- cflags etc. Of course having the right DT_NEEDED
> >> is a good thing regardless.
> >>
> > Thats a good point, pkgconfig doesn't provide that additionally. Perhaps having
> > both is the best solution. As for the DT_NEEDED issues, the earlier threads
> > ennumerated all the problems that were being found with the way the libraries
> > were organized (circular dependencies).
> >
> > Neil
> I am not entirely sure of the conclusion of this thread.
>
> Are we happy with the current linker script solution as a replacement of
> the combined lib?
> Do we want to provide pkg-config file in addition or instead of linker
> script?
Yes pkg-config should be an addition on top of shared/static split/combined
libraries (or linker script). It should be an alternative to mk/rte.app.mk.
> I think I will split the series as there seems to be no objections to
> the patches related to DT_NEEDED entries.
> I'll post a series for DT_NEEDED entries and another series for dealing
> with the combined lib (once we get to an agreement).
>
> Does it sound reasonable?
Yes good idea, thanks.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
2015-04-13 11:04 ` Thomas Monjalon
@ 2015-04-13 11:23 ` Neil Horman
0 siblings, 0 replies; 18+ messages in thread
From: Neil Horman @ 2015-04-13 11:23 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Mon, Apr 13, 2015 at 01:04:52PM +0200, Thomas Monjalon wrote:
> 2015-04-13 10:52, Gonzalez Monroy, Sergio:
> > On 09/04/2015 21:34, Neil Horman wrote:
> > > On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
> > >> On 04/09/2015 02:19 PM, Neil Horman wrote:
> > >>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> > >>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> > >>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
> > >>>>>> On Wed, 8 Apr 2015 16:07:21 +0100
> > >>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> > >>>>>>
> > >>>>>>> Currently, the target/rules to build combined libraries is different
> > >>>>>>> than the one to build individual libraries.
> > >>>>>>>
> > >>>>>>> By removing the combined library option as a build configuration option
> > >>>>>>> we simplify the build pocess by having a single point for
> > >>>>>>> linking/archiving
> > >>>>>>> libraries in DPDK.
> > >>>>>>>
> > >>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> > >>>>>>> removes the makefiles associated with building a combined library.
> > >>>>>>>
> > >>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> > >>>>>>> always generate a linker script that acts as a single combined library.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Sergio Gonzalez Monroy
> > >>>>>>> <sergio.gonzalez.monroy@intel.com>
> > >>>>>> No. We use combined library and it greatly simplfies the application
> > >>>>>> linking process.
> > >>>>>>
> > >>>>> After all the opposition this patch had in v2, I did explain the current
> > >>>>> issues
> > >>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> > >>>>> the agreed solution.
> > >>>>>
> > >>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
> > >>>>> (after applying this patch series) will always generate a very simple
> > >>>>> linker script that behaves as a combined library.
> > >>>>> I encourage you to apply this patch series and try to build your app
> > >>>>> (which links against combined lib).
> > >>>>> Your app should build without problem unless I messed up somewhere and it
> > >>>>> needs fixing.
> > >>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> > >>>> the setting needed to compile and link with dpdk? That will greatly
> > >>>> simplify usage.
> > >>>>
> > >>>> A linker script is just too esoteric.
> > >>>>
> > >>> Why esoteric? We're not talking about a linker script in the sense of a binary
> > >>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> > >>> contains linker directives to include the appropriate libraries. You link it
> > >>> just like you do any other library, but it lets you ignore how they are broken
> > >>> up.
> > >> You mean DT_NEEDED? That's great, but it shouldn't be called a linker
> > >> script.
> > >>
> > > no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
> > > sergio wrote is.
> > >
> > >>> We could certainly do a pkg-config file, but I don't think thats any more
> > >>> adventageous than this solution.
> > >> It solves more problems -- cflags etc. Of course having the right DT_NEEDED
> > >> is a good thing regardless.
> > >>
> > > Thats a good point, pkgconfig doesn't provide that additionally. Perhaps having
> > > both is the best solution. As for the DT_NEEDED issues, the earlier threads
> > > ennumerated all the problems that were being found with the way the libraries
> > > were organized (circular dependencies).
> > >
> > > Neil
> > I am not entirely sure of the conclusion of this thread.
> >
> > Are we happy with the current linker script solution as a replacement of
> > the combined lib?
> > Do we want to provide pkg-config file in addition or instead of linker
> > script?
>
> Yes pkg-config should be an addition on top of shared/static split/combined
> libraries (or linker script). It should be an alternative to mk/rte.app.mk.
>
Adding a pkg-config file I think makes lots of sense.
> > I think I will split the series as there seems to be no objections to
> > the patches related to DT_NEEDED entries.
> > I'll post a series for DT_NEEDED entries and another series for dealing
> > with the combined lib (once we get to an agreement).
> >
> > Does it sound reasonable?
>
yup
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script
2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library Sergio Gonzalez Monroy
` (2 subsequent siblings)
4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
To: dev
After the patch, building DPDK will always generate a linker script
(name use is based on CONFIG_RTE_LIBNAME config option) that behaves
as a combined library when linking against it.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
mk/rte.combinedlib.mk | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++
mk/rte.sdkbuild.mk | 3 ++
2 files changed, 92 insertions(+)
create mode 100644 mk/rte.combinedlib.mk
diff --git a/mk/rte.combinedlib.mk b/mk/rte.combinedlib.mk
new file mode 100644
index 0000000..46d6ee9
--- /dev/null
+++ b/mk/rte.combinedlib.mk
@@ -0,0 +1,89 @@
+# BSD LICENSE
+#
+# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+default: all
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+EXT:=.so
+else
+EXT:=.a
+endif
+
+COMBINEDLIB := lib$(RTE_LIBNAME).so
+
+CORE_LIBS := librte_eal librte_mempool librte_malloc librte_ring
+CORE_LIBS := $(addsuffix $(EXT),$(CORE_LIBS))
+
+ALL_LIBS := $(wildcard $(RTE_OUTPUT)/lib/*$(EXT))
+ALL_LIBS := $(filter-out $(CORE_LIBS),$(notdir $(ALL_LIBS)))
+
+# If we change the combined lib name and we build dpdk without doing
+# 'make uninstall', the previous linker script would be present in the dir.
+filter_type = $(if $(shell file $(lib) | grep "ASCII text"),,$(lib))
+LIBS := $(foreach lib,$(ALL_LIBS),$(filter_type))
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT = INPUT (
+else
+LDSCRIPT = GROUP (
+endif
+
+LDSCRIPT += $(CORE_LIBS)
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT += AS_NEEDED (
+endif
+
+# For shared libs we do not care if we link against PMDs here,
+# they will be ignored (ie. after AS_NEEDED) as there are no direct
+# references to them
+LDSCRIPT += $(LIBS)
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT += )
+endif
+
+LDSCRIPT += )
+
+all: FORCE
+ $(Q)echo "$(LDSCRIPT)" > $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+#
+# Clean all generated files
+#
+.PHONY: clean
+clean:
+ $(Q)rm -f $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+.PHONY: FORCE
+FORCE:
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 2b24e74..625e0c4 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,6 +93,9 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
+ @if [ $@ = lib ]; then \
+ $(MAKE) -f $(RTE_SDK)/mk/rte.combinedlib.mk; \
+ fi
%_clean:
@echo "== Clean $*"
--
1.9.3
^ permalink raw reply [flat|nested] 18+ messages in thread* [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library
2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building Sergio Gonzalez Monroy
4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
To: dev
When creating shared libraries, each library will be linked against
their dependant libraries, specified by the new LDLIBS variable.
Given the circular dependencies between eal, malloc, mempool and ring,
we work around it by not linking eal against its dependent libraries.
Therefore, eal will not have proper DT_NEEDED entries (ie. no DT_NEEDED
entries for librte_malloc and librte_mempool) and we will have to force
link against them by preceding such libraries with --no-as-needed flag.
This patch sets LDLIBS variable for each library and updates DEPDIRS
of some libraries.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
lib/librte_acl/Makefile | 2 ++
lib/librte_cfgfile/Makefile | 2 ++
lib/librte_cmdline/Makefile | 2 ++
lib/librte_distributor/Makefile | 2 ++
lib/librte_eal/bsdapp/eal/Makefile | 2 ++
lib/librte_eal/linuxapp/eal/Makefile | 2 ++
lib/librte_ether/Makefile | 5 ++++-
lib/librte_hash/Makefile | 2 ++
lib/librte_ip_frag/Makefile | 3 +++
lib/librte_ivshmem/Makefile | 2 ++
lib/librte_jobstats/Makefile | 2 ++
lib/librte_kni/Makefile | 2 ++
lib/librte_kvargs/Makefile | 2 ++
lib/librte_lpm/Makefile | 2 ++
lib/librte_malloc/Makefile | 2 ++
lib/librte_mbuf/Makefile | 2 ++
lib/librte_mempool/Makefile | 2 ++
lib/librte_meter/Makefile | 2 ++
lib/librte_pipeline/Makefile | 2 ++
lib/librte_pmd_af_packet/Makefile | 2 ++
lib/librte_pmd_bond/Makefile | 6 ++++++
lib/librte_pmd_e1000/Makefile | 2 ++
lib/librte_pmd_enic/Makefile | 3 +++
lib/librte_pmd_fm10k/Makefile | 2 ++
lib/librte_pmd_i40e/Makefile | 2 ++
lib/librte_pmd_ixgbe/Makefile | 2 ++
lib/librte_pmd_mlx4/Makefile | 2 ++
lib/librte_pmd_null/Makefile | 2 ++
lib/librte_pmd_pcap/Makefile | 2 ++
lib/librte_pmd_ring/Makefile | 4 +++-
lib/librte_pmd_virtio/Makefile | 2 ++
lib/librte_pmd_vmxnet3/Makefile | 2 ++
lib/librte_pmd_xenvirt/Makefile | 3 +++
lib/librte_port/Makefile | 4 ++++
lib/librte_power/Makefile | 2 ++
lib/librte_reorder/Makefile | 2 ++
lib/librte_ring/Makefile | 2 ++
lib/librte_sched/Makefile | 2 ++
lib/librte_table/Makefile | 4 ++++
lib/librte_timer/Makefile | 2 ++
lib/librte_vhost/Makefile | 7 +++++--
41 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 68dc248..00f5e33 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_acl_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c
diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index 032c240..babe7d1 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_cfgfile_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile
index 719dff6..0f7935f 100644
--- a/lib/librte_cmdline/Makefile
+++ b/lib/librte_cmdline/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_cmdline_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := cmdline.c
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_cirbuf.c
diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 4c9af17..b275491 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_distributor_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mbuf
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index 2357cfa..8d7a6fc 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -46,6 +46,8 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_ring
CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_pcap
CFLAGS += $(WERROR_FLAGS) -O3
+LDLIBS += -lrt
+
EXPORT_MAP := rte_eal_version.map
LIBABIVER := 1
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 01f7b70..c351a38 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -53,6 +53,8 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_af_packet
CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
CFLAGS += $(WERROR_FLAGS) -O3
+LDLIBS += -lrt
+
# specific to linuxapp exec-env
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) := eal.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_hugepage_info.c
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index c0e5768..a1059d7 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_ether_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mempool -lrte_ring -lrte_malloc
+
SRCS-y += rte_ethdev.c
#
@@ -53,6 +55,7 @@ SYMLINK-y-include += rte_ethdev.h
SYMLINK-y-include += rte_eth_ctrl.h
# this lib depends upon:
-DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring lib/librte_mbuf
+DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring
+DEPDIRS-y += lib/librte_mbuf lib/librte_malloc
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
index 3696cb1..bc9bfc7 100644
--- a/lib/librte_hash/Makefile
+++ b/lib/librte_hash/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_hash_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_HASH) := rte_hash.c
SRCS-$(CONFIG_RTE_LIBRTE_HASH) += rte_fbk_hash.c
diff --git a/lib/librte_ip_frag/Makefile b/lib/librte_ip_frag/Makefile
index 9d06780..ee72ab4 100644
--- a/lib/librte_ip_frag/Makefile
+++ b/lib/librte_ip_frag/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_ipfrag_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
#source files
SRCS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += rte_ipv4_fragmentation.c
SRCS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += rte_ipv6_fragmentation.c
@@ -55,5 +57,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_IP_FRAG)-include += rte_ip_frag.h
# this library depends on rte_ether
DEPDIRS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += lib/librte_mempool lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += lib/librte_malloc lib/librte_mbuf
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ivshmem/Makefile b/lib/librte_ivshmem/Makefile
index 16defdb..fab6f5f 100644
--- a/lib/librte_ivshmem/Makefile
+++ b/lib/librte_ivshmem/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_ivshmem_version.map
LIBABIVER := 1
+LDLIBS += -lrte_mempool
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_IVSHMEM) := rte_ivshmem.c
diff --git a/lib/librte_jobstats/Makefile b/lib/librte_jobstats/Makefile
index 136a448..04589d4 100644
--- a/lib/librte_jobstats/Makefile
+++ b/lib/librte_jobstats/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_jobstats_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_JOBSTATS) := rte_jobstats.c
diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile
index 7107832..504ecf7 100644
--- a/lib/librte_kni/Makefile
+++ b/lib/librte_kni/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_kni_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_KNI) := rte_kni.c
diff --git a/lib/librte_kvargs/Makefile b/lib/librte_kvargs/Makefile
index 87b09f2..173e1ac 100644
--- a/lib/librte_kvargs/Makefile
+++ b/lib/librte_kvargs/Makefile
@@ -42,6 +42,8 @@ EXPORT_MAP := rte_kvargs_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) := rte_kvargs.c
diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile
index 35e6389..125d52e 100644
--- a/lib/librte_lpm/Makefile
+++ b/lib/librte_lpm/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_lpm_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c
diff --git a/lib/librte_malloc/Makefile b/lib/librte_malloc/Makefile
index 947e41c..3e7348f 100644
--- a/lib/librte_malloc/Makefile
+++ b/lib/librte_malloc/Makefile
@@ -40,6 +40,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
EXPORT_MAP := rte_malloc_version.map
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MALLOC) := rte_malloc.c malloc_elem.c malloc_heap.c
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index 080f3cf..d819891 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_mbuf_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c
diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index 940d1f7..8ebebb6 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_mempool_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc -lrte_ring
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool.c
ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile
index 8765881..d5eafb0 100644
--- a/lib/librte_meter/Makefile
+++ b/lib/librte_meter/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_meter_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile
index 15e406b..16de0a3 100644
--- a/lib/librte_pipeline/Makefile
+++ b/lib/librte_pipeline/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_pipeline_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_af_packet/Makefile b/lib/librte_pmd_af_packet/Makefile
index f0bf537..14a9957 100644
--- a/lib/librte_pmd_af_packet/Makefile
+++ b/lib/librte_pmd_af_packet/Makefile
@@ -45,6 +45,8 @@ LIBABIVER := 1
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_malloc -lethdev -lrte_kvargs
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_bond/Makefile b/lib/librte_pmd_bond/Makefile
index 83ccce3..d046489 100644
--- a/lib/librte_pmd_bond/Makefile
+++ b/lib/librte_pmd_bond/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_eth_bond_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_ring -lrte_mempool -lrte_malloc
+LDLIBS += -lethdev -lrte_kvargs -lrte_cmdline
+
#
# all source are stored in SRCS-y
#
@@ -59,10 +62,13 @@ SYMLINK-y-include += rte_eth_bond.h
SYMLINK-y-include += rte_eth_bond_8023ad.h
# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_ring
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_mempool
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_mbuf
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_ether
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_malloc
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_eal
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_kvargs
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_cmdline
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_pmd_e1000/Makefile b/lib/librte_pmd_e1000/Makefile
index 8c8fed8..5af6b6a 100644
--- a/lib/librte_pmd_e1000/Makefile
+++ b/lib/librte_pmd_e1000/Makefile
@@ -65,6 +65,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
VPATH += $(RTE_SDK)/lib/librte_pmd_e1000/e1000
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
index 251a898..e0100b2 100644
--- a/lib/librte_pmd_enic/Makefile
+++ b/lib/librte_pmd_enic/Makefile
@@ -48,6 +48,9 @@ CFLAGS += $(WERROR_FLAGS) -Wno-strict-aliasing
VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc
+LDLIBS += -lethdev -lrte_hash
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_fm10k/Makefile b/lib/librte_pmd_fm10k/Makefile
index 7516d37..9ee0d48 100644
--- a/lib/librte_pmd_fm10k/Makefile
+++ b/lib/librte_pmd_fm10k/Makefile
@@ -81,6 +81,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
VPATH += $(RTE_SDK)/lib/librte_pmd_fm10k/base
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile
index 64bab16..fa0d858 100644
--- a/lib/librte_pmd_i40e/Makefile
+++ b/lib/librte_pmd_i40e/Makefile
@@ -80,6 +80,8 @@ $(foreach obj, $(OBJS_BASE_DRIVER), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
VPATH += $(RTE_SDK)/lib/librte_pmd_i40e/i40e
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile
index ae36202..d96edf2 100644
--- a/lib/librte_pmd_ixgbe/Makefile
+++ b/lib/librte_pmd_ixgbe/Makefile
@@ -91,6 +91,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
VPATH += $(RTE_SDK)/lib/librte_pmd_ixgbe/ixgbe
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_mlx4/Makefile b/lib/librte_pmd_mlx4/Makefile
index 97b364a..a367748 100644
--- a/lib/librte_pmd_mlx4/Makefile
+++ b/lib/librte_pmd_mlx4/Makefile
@@ -58,6 +58,8 @@ CFLAGS += -Wno-error=cast-qual
EXPORT_MAP := rte_pmd_mlx4_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_malloc -lethdev -libverbs
+
# DEBUG which is usually provided on the command-line may enable
# CONFIG_RTE_LIBRTE_MLX4_DEBUG.
ifeq ($(DEBUG),1)
diff --git a/lib/librte_pmd_null/Makefile b/lib/librte_pmd_null/Makefile
index 6472015..c9bf1fd 100644
--- a/lib/librte_pmd_null/Makefile
+++ b/lib/librte_pmd_null/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_pmd_null_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc -lethdev -lrte_kvargs
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_pcap/Makefile b/lib/librte_pmd_pcap/Makefile
index 0775dbc..2717978 100644
--- a/lib/librte_pmd_pcap/Makefile
+++ b/lib/librte_pmd_pcap/Makefile
@@ -44,6 +44,8 @@ EXPORT_MAP := rte_pmd_pcap_version.map
LIBABIVER := 1
+LDLIBS += -lrte_mbuf -lrte_malloc -lethdev -lrte_kvargs -lpcap
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_ring/Makefile b/lib/librte_pmd_ring/Makefile
index e442d0b..33a4fb3 100644
--- a/lib/librte_pmd_ring/Makefile
+++ b/lib/librte_pmd_ring/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_eth_ring_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_ring -lrte_malloc -lethdev -lrte_kvargs
+
#
# all source are stored in SRCS-y
#
@@ -56,6 +58,6 @@ SYMLINK-y-include += rte_eth_ring.h
# this lib depends upon:
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_eal lib/librte_ring
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_mbuf lib/librte_ether
-DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_kvargs
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_kvargs lib/librte_malloc
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_pmd_virtio/Makefile b/lib/librte_pmd_virtio/Makefile
index 793067f..25f7928 100644
--- a/lib/librte_pmd_virtio/Makefile
+++ b/lib/librte_pmd_virtio/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_pmd_virtio_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile
index fc616c4..35c0c90 100644
--- a/lib/librte_pmd_vmxnet3/Makefile
+++ b/lib/librte_pmd_vmxnet3/Makefile
@@ -70,6 +70,8 @@ EXPORT_MAP := rte_pmd_vmxnet3_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_pmd_xenvirt/Makefile b/lib/librte_pmd_xenvirt/Makefile
index f0c796c..df39a6e 100644
--- a/lib/librte_pmd_xenvirt/Makefile
+++ b/lib/librte_pmd_xenvirt/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_eth_xenvirt_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc
+LDLIBS += -lethdev -rte_cmdline -xenstore
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_port/Makefile b/lib/librte_port/Makefile
index de960fc..595a682 100644
--- a/lib/librte_port/Makefile
+++ b/lib/librte_port/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_port_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mempool -lrte_malloc
+LDLIBS += -lethdev -lrte_ip_frag -lrte_sched
+
#
# all source are stored in SRCS-y
#
@@ -73,5 +76,6 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_mempool
DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_malloc
DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ether
DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ip_frag
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_sched
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_power/Makefile b/lib/librte_power/Makefile
index cee95cd..ec9107e 100644
--- a/lib/librte_power/Makefile
+++ b/lib/librte_power/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_power_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_POWER) := rte_power.c rte_power_acpi_cpufreq.c
SRCS-$(CONFIG_RTE_LIBRTE_POWER) += rte_power_kvm_vm.c guest_channel.c
diff --git a/lib/librte_reorder/Makefile b/lib/librte_reorder/Makefile
index 0c01de1..2c8f774 100644
--- a/lib/librte_reorder/Makefile
+++ b/lib/librte_reorder/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_reorder_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_REORDER) := rte_reorder.c
diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
index 84ad3d3..1ff6cb6 100644
--- a/lib/librte_ring/Makefile
+++ b/lib/librte_ring/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_ring_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index b1cb285..a3ac216 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -45,6 +45,8 @@ EXPORT_MAP := rte_sched_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_malloc
+
#
# all source are stored in SRCS-y
#
diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile
index 0d8394c..2254d52 100644
--- a/lib/librte_table/Makefile
+++ b/lib/librte_table/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_table_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc
+LDLIBS += -lrte_port -lrte_lpm -lrte_hash
+
#
# all source are stored in SRCS-y
#
@@ -80,6 +83,7 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_port
DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_lpm
ifeq ($(CONFIG_RTE_LIBRTE_ACL),y)
DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_acl
+LDLIBS += -lrte_acl
endif
DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_hash
diff --git a/lib/librte_timer/Makefile b/lib/librte_timer/Makefile
index 2aabef8..859fa1a 100644
--- a/lib/librte_timer/Makefile
+++ b/lib/librte_timer/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_timer_version.map
LIBABIVER := 1
+LDLIBS += -lrte_eal
+
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_TIMER) := rte_timer.c
diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
index a8645a6..ac486ce 100644
--- a/lib/librte_vhost/Makefile
+++ b/lib/librte_vhost/Makefile
@@ -39,11 +39,14 @@ EXPORT_MAP := rte_vhost_version.map
LIBABIVER := 1
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64
+
+LDLIBS += -lrte_eal -lrte_mbuf -lethdev
+
ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),y)
CFLAGS += -I vhost_user
else
-CFLAGS += -I vhost_cuse -lfuse
-LDFLAGS += -lfuse
+CFLAGS += -I vhost_cuse
+LDLIBS += -lfuse
endif
# all source are stored in SRCS-y
--
1.9.3
^ permalink raw reply [flat|nested] 18+ messages in thread
* [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries
2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
` (2 preceding siblings ...)
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building Sergio Gonzalez Monroy
4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
To: dev
This patch mainly makes use of the LDLIBS variable when linking shared
libraries, setting proper DT_NEEDED entries.
This patch also fixes a few nits like syntax highlighting, the command
string (O_TO_S_CMD) used for linking shared libraries and the displayed
of dependencies when debugging is enable (D).
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
mk/rte.lib.mk | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index d96101a..603badf 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -62,16 +62,19 @@ build: _postbuild
exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1))))
+_LDLIBS := --as-needed $(LDLIBS) $(EXECENV_LDLIBS) --no-as-needed
+
ifeq ($(LINK_USING_CC),1)
# Override the definition of LD here, since we're linking with CC
LD := $(CC) $(CPU_CFLAGS)
_CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS))
+_LDLIBS := $(call linkerprefix,$(_LDLIBS))
else
_CPU_LDFLAGS := $(CPU_LDFLAGS)
endif
O_TO_A = $(AR) crus $(LIB) $(OBJS-y)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
+O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #')# fix syntax highlight
O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)"," AR $(@)")
O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
O_TO_A_DO = @set -e; \
@@ -79,9 +82,11 @@ O_TO_A_DO = @set -e; \
$(O_TO_A) && \
echo $(O_TO_A_CMD) > $(call exe2cmd,$(@))
-O_TO_S = $(LD) $(_CPU_LDFLAGS) -shared $(OBJS-y) -Wl,-soname,$(LIB) -o $(LIB)
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
+O_TO_S = $(LD) $(_CPU_LDFLAGS) -L $(RTE_OUTPUT)/lib -Wl,-soname,$(LIB) \
+ -shared $(OBJS-y) $(_LDLIBS) -o $(LIB)
+O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #')# fix syntax highlight
O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)")
+O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
O_TO_S_DO = @set -e; \
echo $(O_TO_S_DISP); \
$(O_TO_S) && \
@@ -100,7 +105,7 @@ ifeq ($(LIBABIVER),)
endif
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
$(if $(D),\
- @echo -n "$< -> $@ " ; \
+ @echo -n "$? -> $@ " ; \
echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
echo -n "cmdline_changed=$(call boolean,$(call cmdline_changed,$(O_TO_S_STR))) " ; \
echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \
@@ -115,7 +120,7 @@ else
$(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
$(if $(D),\
- @echo -n "$< -> $@ " ; \
+ @echo -n "$? -> $@ " ; \
echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
echo -n "cmdline_changed=$(call boolean,$(call cmdline_changed,$(O_TO_A_STR))) " ; \
echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \
--
1.9.3
^ permalink raw reply [flat|nested] 18+ messages in thread* [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building
2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
` (3 preceding siblings ...)
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
To: dev
Given the circular dependencies between eal, malloc, mempool and ring
libraries and that eal does not have proper DT_NEEDED entries, we work
around it by forcing linking against mentioned libraries by preceding
them with --no-as-needed flag when building shared libraries.
This patch also does:
- Set --start-group/--end-group and --whole-archive/--no-whole-archive
flags only when linking against static DPDK libs.
- Set --as-needed for all libraries but eal, malloc, mempool and
ring when linking against shared DPDK libs.
- Link against EXECENV_LIBS always with --as-needed flag.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
mk/rte.app.mk | 54 ++++++++++++++++++++++++++++++------------------------
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index e8630b6..2d6b2ca 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -59,7 +59,30 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib
#
ifeq ($(NO_AUTOLIBS),)
-LDLIBS += --whole-archive
+LDLIBS += --no-as-needed
+ifneq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDLIBS += --start-group
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_EAL),y)
+LDLIBS += -lrte_eal
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y)
+LDLIBS += -lrte_malloc
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y)
+LDLIBS += -lrte_mempool
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_RING),y)
+LDLIBS += -lrte_ring
+endif
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDLIBS += --as-needed
+endif
ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
LDLIBS += -lrte_distributor
@@ -127,7 +150,7 @@ LDLIBS += -lm
LDLIBS += -lrt
endif
-ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
+ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
LDLIBS += -lrte_vhost
endif
@@ -143,8 +166,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_MLX4_PMD),y)
LDLIBS += -libverbs
endif
-LDLIBS += --start-group
-
ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
LDLIBS += -lrte_kvargs
endif
@@ -161,22 +182,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_ETHER),y)
LDLIBS += -lethdev
endif
-ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y)
-LDLIBS += -lrte_malloc
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y)
-LDLIBS += -lrte_mempool
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_RING),y)
-LDLIBS += -lrte_ring
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_EAL),y)
-LDLIBS += -lrte_eal
-endif
-
ifeq ($(CONFIG_RTE_LIBRTE_CMDLINE),y)
LDLIBS += -lrte_cmdline
endif
@@ -196,6 +201,7 @@ endif
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
# plugins (link only if static libraries)
+LDLIBS += --whole-archive
ifeq ($(CONFIG_RTE_LIBRTE_VMXNET3_PMD),y)
LDLIBS += -lrte_pmd_vmxnet3_uio
@@ -241,14 +247,14 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_AF_PACKET),y)
LDLIBS += -lrte_pmd_af_packet
endif
+LDLIBS += --no-whole-archive
+LDLIBS += --end-group
+LDLIBS += --as-needed
+
endif # plugins
LDLIBS += $(EXECENV_LDLIBS)
-LDLIBS += --end-group
-
-LDLIBS += --no-whole-archive
-
endif # ifeq ($(NO_AUTOLIBS),)
LDLIBS += $(CPU_LDLIBS)
--
1.9.3
^ permalink raw reply [flat|nested] 18+ messages in thread