* [PATCH 0/8] Improve build process
@ 2015-01-29 15:20 Sergio Gonzalez Monroy
[not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 63+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw)
To: dev-VfR2kkLFssw
This patch series improves the DPDK build system mostly for shared
libraries (and a few nits for static libraries) with the following goals:
- Create a library containing core DPDK libraries (librte_eal,
librte_malloc, librte_mempool, librte_mbuf and librte_ring).
The idea of core libraries is to group those libraries that are
always required (and have interdependencies) for any DPDK application.
- Remove config option to build a combined library.
- For shared libraries, explicitly link against dependant
libraries (adding entries to DT_NEEDED).
- Update app linking flags for static/shared DPDK libs.
Sergio Gonzalez Monroy (8):
mk: remove combined library and related options
core: create new librte_core
mk: new corelib makefile
lib: update DEPDIRS variable
lib: set LDLIBS for each library
mk: use LDLIBS when linking shared libraries
mk: update LDLIBS for app building
mk: add -lpthread to linuxapp EXECENV_LDLIBS
config/common_bsdapp | 6 --
config/common_linuxapp | 6 --
config/defconfig_ppc_64-power8-linuxapp-gcc | 2 -
lib/Makefile | 1 -
lib/librte_acl/Makefile | 5 +-
lib/librte_cfgfile/Makefile | 4 +-
lib/librte_cmdline/Makefile | 6 +-
lib/librte_core/Makefile | 45 +++++++++++++
lib/librte_distributor/Makefile | 5 +-
lib/librte_eal/bsdapp/eal/Makefile | 3 +-
lib/librte_eal/linuxapp/eal/Makefile | 3 +-
lib/librte_ether/Makefile | 4 +-
lib/librte_hash/Makefile | 4 +-
lib/librte_ip_frag/Makefile | 6 +-
lib/librte_ivshmem/Makefile | 4 +-
lib/librte_kni/Makefile | 6 +-
lib/librte_kvargs/Makefile | 6 +-
lib/librte_lpm/Makefile | 6 +-
lib/librte_malloc/Makefile | 2 +-
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mempool/Makefile | 2 +-
lib/librte_meter/Makefile | 4 +-
lib/librte_pipeline/Makefile | 3 +
lib/librte_pmd_af_packet/Makefile | 5 +-
lib/librte_pmd_bond/Makefile | 7 +-
lib/librte_pmd_e1000/Makefile | 8 ++-
lib/librte_pmd_enic/Makefile | 8 ++-
lib/librte_pmd_i40e/Makefile | 8 ++-
lib/librte_pmd_ixgbe/Makefile | 8 ++-
lib/librte_pmd_pcap/Makefile | 5 +-
lib/librte_pmd_ring/Makefile | 6 +-
lib/librte_pmd_virtio/Makefile | 7 +-
lib/librte_pmd_vmxnet3/Makefile | 8 ++-
lib/librte_pmd_xenvirt/Makefile | 8 ++-
lib/librte_port/Makefile | 8 +--
lib/librte_power/Makefile | 4 +-
lib/librte_ring/Makefile | 2 +-
lib/librte_sched/Makefile | 7 +-
lib/librte_table/Makefile | 8 +--
lib/librte_timer/Makefile | 6 +-
lib/librte_vhost/Makefile | 9 +--
mk/exec-env/linuxapp/rte.vars.mk | 2 +
mk/rte.app.mk | 53 ++++-----------
mk/rte.corelib.mk | 84 +++++++++++++++++++++++
mk/rte.lib.mk | 49 +++-----------
mk/rte.sdkbuild.mk | 3 -
mk/rte.sharelib.mk | 101 ----------------------------
mk/rte.vars.mk | 9 ---
48 files changed, 276 insertions(+), 282 deletions(-)
create mode 100644 lib/librte_core/Makefile
create mode 100644 mk/rte.corelib.mk
delete mode 100644 mk/rte.sharelib.mk
--
1.9.3
^ permalink raw reply [flat|nested] 63+ messages in thread[parent not found: <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* [PATCH 1/8] mk: remove combined library and related options [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 2/8] core: create new librte_core Sergio Gonzalez Monroy ` (8 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- config/common_bsdapp | 6 -- config/common_linuxapp | 6 -- config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - lib/Makefile | 1 - mk/rte.app.mk | 12 ---- mk/rte.lib.mk | 34 ---------- mk/rte.sdkbuild.mk | 3 - mk/rte.sharelib.mk | 101 ---------------------------- mk/rte.vars.mk | 9 --- 9 files changed, 174 deletions(-) delete mode 100644 mk/rte.sharelib.mk diff --git a/config/common_bsdapp b/config/common_bsdapp index 9177db1..812a6ca 100644 --- a/config/common_bsdapp +++ b/config/common_bsdapp @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n CONFIG_RTE_BUILD_SHARED_LIB=n # -# Combine to one single library -# -CONFIG_RTE_BUILD_COMBINE_LIBS=n -CONFIG_RTE_LIBNAME=intel_dpdk - -# # Compile Environment Abstraction Layer # CONFIG_RTE_LIBRTE_EAL=y diff --git a/config/common_linuxapp b/config/common_linuxapp index 2f9643b..e35ad2b 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n CONFIG_RTE_BUILD_SHARED_LIB=n # -# Combine to one single library -# -CONFIG_RTE_BUILD_COMBINE_LIBS=n -CONFIG_RTE_LIBNAME="intel_dpdk" - -# # Compile Environment Abstraction Layer # CONFIG_RTE_LIBRTE_EAL=y diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8-linuxapp-gcc index d97a885..f1af518 100644 --- a/config/defconfig_ppc_64-power8-linuxapp-gcc +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc @@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y -CONFIG_RTE_LIBNAME="powerpc_dpdk" - # Note: Power doesn't have this support CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n diff --git a/lib/Makefile b/lib/Makefile index 0ffc982..bafc9ae 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -71,5 +71,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 4294d9a..4c70743 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 @@ -125,8 +119,6 @@ LDLIBS += -lm LDLIBS += -lrt endif -endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS - ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) LDLIBS += -lpcap endif @@ -137,8 +129,6 @@ endif LDLIBS += --start-group -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) - ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y) LDLIBS += -lrte_kvargs endif @@ -233,8 +223,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 81bf8e1..7c99fd1 100644 --- a/mk/rte.lib.mk +++ b/mk/rte.lib.mk @@ -84,24 +84,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 # @@ -122,14 +104,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE $(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 $@) @@ -145,14 +119,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 d5b36be..316c35b 100644 --- a/mk/rte.vars.mk +++ b/mk/rte.vars.mk @@ -67,15 +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:"%"=%) -ifeq ($(RTE_LIBNAME),) -RTE_LIBNAME := intel_dpdk endif # RTE_TARGET is deducted from config when we are building the SDK. -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 2/8] core: create new librte_core [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-01-29 15:20 ` [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 3/8] mk: new corelib makefile Sergio Gonzalez Monroy ` (7 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw This is a synthetic library used to stage the DPDK building. The goal is to produce a librte_core library that contains all the core libraries. When building the DPDK, all object files from core libraries would be moved to the build directory of librte_core. When building librte_core, the build system will link/archive all objects found in the directory. This patch sets the following libraries as core: librte_eal, librte_mempool, librte_malloc, librte_mbufs and librte_ring. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- lib/Makefile | 1 + lib/librte_core/Makefile | 45 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 lib/librte_core/Makefile diff --git a/lib/Makefile b/lib/Makefile index bafc9ae..0e4cec3 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -31,6 +31,7 @@ include $(RTE_SDK)/mk/rte.vars.mk +DIRS-y += librte_core DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal DIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += librte_malloc DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring diff --git a/lib/librte_core/Makefile b/lib/librte_core/Makefile new file mode 100644 index 0000000..266bd16 --- /dev/null +++ b/lib/librte_core/Makefile @@ -0,0 +1,45 @@ +# 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/rte.vars.mk + +# library name +LIB = librte_core.a + +SRCS-y = $(wildcard *.o) + +DEPDIRS-y += lib/librte_eal +DEPDIRS-y += lib/librte_mempool +DEPDIRS-y += lib/librte_malloc +DEPDIRS-y += lib/librte_mbuf +DEPDIRS-y += lib/librte_ring + +include $(RTE_SDK)/mk/rte.lib.mk -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 3/8] mk: new corelib makefile [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-01-29 15:20 ` [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 2/8] core: create new librte_core Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 4/8] lib: update DEPDIRS variable Sergio Gonzalez Monroy ` (6 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw This patch creates a new rte.corelib.mk file and updates core libraries to use it instead of rte.lib.mk Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- lib/librte_eal/bsdapp/eal/Makefile | 3 +- lib/librte_eal/linuxapp/eal/Makefile | 3 +- lib/librte_malloc/Makefile | 2 +- lib/librte_mbuf/Makefile | 2 +- lib/librte_mempool/Makefile | 2 +- lib/librte_ring/Makefile | 2 +- mk/rte.corelib.mk | 84 ++++++++++++++++++++++++++++++++++++ 7 files changed, 90 insertions(+), 8 deletions(-) create mode 100644 mk/rte.corelib.mk diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile index d434882..7acdf05 100644 --- a/lib/librte_eal/bsdapp/eal/Makefile +++ b/lib/librte_eal/bsdapp/eal/Makefile @@ -93,5 +93,4 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP)-include/exec-env := \ DEPDIRS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += lib/librte_eal/common -include $(RTE_SDK)/mk/rte.lib.mk - +include $(RTE_SDK)/mk/rte.corelib.mk diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile index 72ecf3a..6fc7b3d 100644 --- a/lib/librte_eal/linuxapp/eal/Makefile +++ b/lib/librte_eal/linuxapp/eal/Makefile @@ -108,5 +108,4 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP)-include/exec-env := \ DEPDIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += lib/librte_eal/common -include $(RTE_SDK)/mk/rte.lib.mk - +include $(RTE_SDK)/mk/rte.corelib.mk diff --git a/lib/librte_malloc/Makefile b/lib/librte_malloc/Makefile index ba87e34..6b8a3d8 100644 --- a/lib/librte_malloc/Makefile +++ b/lib/librte_malloc/Makefile @@ -45,4 +45,4 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_MALLOC)-include := rte_malloc.h # this lib needs eal DEPDIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += lib/librte_eal -include $(RTE_SDK)/mk/rte.lib.mk +include $(RTE_SDK)/mk/rte.corelib.mk diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile index 9b45ba4..c2ca3ff 100644 --- a/lib/librte_mbuf/Makefile +++ b/lib/librte_mbuf/Makefile @@ -45,4 +45,4 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h # this lib needs eal DEPDIRS-$(CONFIG_RTE_LIBRTE_MBUF) += lib/librte_eal lib/librte_mempool -include $(RTE_SDK)/mk/rte.lib.mk +include $(RTE_SDK)/mk/rte.corelib.mk diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile index 9939e10..6748607 100644 --- a/lib/librte_mempool/Makefile +++ b/lib/librte_mempool/Makefile @@ -48,4 +48,4 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_MEMPOOL)-include := rte_mempool.h DEPDIRS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += lib/librte_eal lib/librte_ring DEPDIRS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += lib/librte_malloc -include $(RTE_SDK)/mk/rte.lib.mk +include $(RTE_SDK)/mk/rte.corelib.mk diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile index 2380a43..429916e 100644 --- a/lib/librte_ring/Makefile +++ b/lib/librte_ring/Makefile @@ -45,4 +45,4 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h # this lib needs eal and rte_malloc DEPDIRS-$(CONFIG_RTE_LIBRTE_RING) += lib/librte_eal lib/librte_malloc -include $(RTE_SDK)/mk/rte.lib.mk +include $(RTE_SDK)/mk/rte.corelib.mk diff --git a/mk/rte.corelib.mk b/mk/rte.corelib.mk new file mode 100644 index 0000000..8b57e91 --- /dev/null +++ b/mk/rte.corelib.mk @@ -0,0 +1,84 @@ +# 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.compile-pre.mk +include $(RTE_SDK)/mk/internal/rte.install-pre.mk +include $(RTE_SDK)/mk/internal/rte.clean-pre.mk +include $(RTE_SDK)/mk/internal/rte.build-pre.mk +include $(RTE_SDK)/mk/internal/rte.depdirs-pre.mk + +# VPATH contains at least SRCDIR +VPATH += $(SRCDIR) + +LIB := $(patsubst %.a,%.touch,$(LIB)) + +# Copy all objects to the core dir +COREDIR := $(RTE_OUTPUT)/build/lib/librte_core + +_BUILD = $(LIB) +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) +_CLEAN = doclean + +.PHONY: all +all: install + +.PHONY: install +install: build _postinstall + +_postinstall: build + +.PHONY: build +build: _postbuild + +$(LIB): $(OBJS-y) + @mkdir -p $(COREDIR) + @cp -f $? $(COREDIR) && touch $(LIB) + +# +# Clean all generated files +# +.PHONY: clean +clean: _postclean + +.PHONY: doclean +doclean: + $(Q)rm -rf $(LIB) $(OBJS-all) $(DEPS-all) $(DEPSTMP-all) \ + $(CMDS-all) $(INSTALL-FILES-all) + $(Q)rm -f $(_BUILD_TARGETS) $(_INSTALL_TARGETS) $(_CLEAN_TARGETS) + +include $(RTE_SDK)/mk/internal/rte.compile-post.mk +include $(RTE_SDK)/mk/internal/rte.install-post.mk +include $(RTE_SDK)/mk/internal/rte.clean-post.mk +include $(RTE_SDK)/mk/internal/rte.build-post.mk +include $(RTE_SDK)/mk/internal/rte.depdirs-post.mk + +.PHONY: FORCE +FORCE: -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 4/8] lib: update DEPDIRS variable [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (2 preceding siblings ...) 2015-01-29 15:20 ` [PATCH 3/8] mk: new corelib makefile Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 5/8] lib: set LDLIBS for each library Sergio Gonzalez Monroy ` (5 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw This patch updates the DEPDIRS variable of all DPDK libraries so they depend on librte_core instead of any of the core libraries. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- lib/librte_acl/Makefile | 4 ++-- lib/librte_cfgfile/Makefile | 2 +- lib/librte_cmdline/Makefile | 4 ++-- lib/librte_distributor/Makefile | 3 +-- lib/librte_ether/Makefile | 2 +- lib/librte_hash/Makefile | 2 +- lib/librte_ip_frag/Makefile | 4 ++-- lib/librte_ivshmem/Makefile | 2 +- lib/librte_kni/Makefile | 4 ++-- lib/librte_kvargs/Makefile | 4 ++-- lib/librte_lpm/Makefile | 4 ++-- lib/librte_meter/Makefile | 2 +- lib/librte_pipeline/Makefile | 1 + lib/librte_pmd_af_packet/Makefile | 3 +-- lib/librte_pmd_bond/Makefile | 5 ++--- lib/librte_pmd_e1000/Makefile | 6 +++--- lib/librte_pmd_enic/Makefile | 6 +++--- lib/librte_pmd_i40e/Makefile | 6 +++--- lib/librte_pmd_ixgbe/Makefile | 6 +++--- lib/librte_pmd_pcap/Makefile | 3 +-- lib/librte_pmd_ring/Makefile | 4 ++-- lib/librte_pmd_virtio/Makefile | 6 +++--- lib/librte_pmd_vmxnet3/Makefile | 6 +++--- lib/librte_pmd_xenvirt/Makefile | 6 +++--- lib/librte_port/Makefile | 6 ++---- lib/librte_power/Makefile | 2 +- lib/librte_sched/Makefile | 5 +++-- lib/librte_table/Makefile | 5 +---- lib/librte_timer/Makefile | 4 ++-- lib/librte_vhost/Makefile | 3 +-- 30 files changed, 56 insertions(+), 64 deletions(-) diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile index 6b74dc9..926cb0d 100644 --- a/lib/librte_acl/Makefile +++ b/lib/librte_acl/Makefile @@ -74,8 +74,8 @@ ifeq ($(CONFIG_RTE_LIBRTE_ACL_STANDALONE),y) # standalone build SYMLINK-$(CONFIG_RTE_LIBRTE_ACL)-include += rte_acl_osdep_alone.h else -# this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_ACL) += lib/librte_eal lib/librte_malloc +# this lib needs +DEPDIRS-$(CONFIG_RTE_LIBRTE_ACL) += lib/librte_core endif include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile index 55e8701..2668230 100644 --- a/lib/librte_cfgfile/Makefile +++ b/lib/librte_cfgfile/Makefile @@ -48,6 +48,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_CFGFILE) += rte_cfgfile.c SYMLINK-$(CONFIG_RTE_LIBRTE_CFGFILE)-include += rte_cfgfile.h # this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += lib/librte_eal +DEPDIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile index 7eae449..e72e11d 100644 --- a/lib/librte_cmdline/Makefile +++ b/lib/librte_cmdline/Makefile @@ -57,7 +57,7 @@ INCS += cmdline_parse_etheraddr.h cmdline_parse_string.h cmdline_rdline.h INCS += cmdline_vt100.h cmdline_socket.h cmdline_cirbuf.h cmdline_parse_portlist.h SYMLINK-$(CONFIG_RTE_LIBRTE_CMDLINE)-include := $(INCS) -# this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += lib/librte_eal +# this lib needs +DEPDIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile index 36699f8..01df4fa 100644 --- a/lib/librte_distributor/Makefile +++ b/lib/librte_distributor/Makefile @@ -44,7 +44,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c SYMLINK-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR)-include := rte_distributor.h # this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += lib/librte_eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += lib/librte_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile index a461c31..226313b 100644 --- a/lib/librte_ether/Makefile +++ b/lib/librte_ether/Makefile @@ -49,6 +49,6 @@ 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_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile index 95e4c09..6bd8fe5 100644 --- a/lib/librte_hash/Makefile +++ b/lib/librte_hash/Makefile @@ -48,6 +48,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_jhash.h SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_fbk_hash.h # this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_HASH) += lib/librte_eal lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_HASH) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_ip_frag/Makefile b/lib/librte_ip_frag/Makefile index 8c00d39..eedb94a 100644 --- a/lib/librte_ip_frag/Makefile +++ b/lib/librte_ip_frag/Makefile @@ -53,7 +53,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += ip_frag_internal.c 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 +# this library depends upon: +DEPDIRS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += lib/librte_core lib/librte_ether include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_ivshmem/Makefile b/lib/librte_ivshmem/Makefile index 536814c..4a6cca5 100644 --- a/lib/librte_ivshmem/Makefile +++ b/lib/librte_ivshmem/Makefile @@ -43,6 +43,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_IVSHMEM) := rte_ivshmem.c SYMLINK-$(CONFIG_RTE_LIBRTE_IVSHMEM)-include := rte_ivshmem.h # this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += lib/librte_mempool +DEPDIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile index 5267304..0b9a261 100644 --- a/lib/librte_kni/Makefile +++ b/lib/librte_kni/Makefile @@ -42,8 +42,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_KNI) := rte_kni.c # install includes SYMLINK-$(CONFIG_RTE_LIBRTE_KNI)-include := rte_kni.h -# this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_KNI) += lib/librte_eal lib/librte_mbuf +# this lib needs +DEPDIRS-$(CONFIG_RTE_LIBRTE_KNI) += lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_KNI) += lib/librte_ether include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_kvargs/Makefile b/lib/librte_kvargs/Makefile index b09359a..6564335 100644 --- a/lib/librte_kvargs/Makefile +++ b/lib/librte_kvargs/Makefile @@ -45,7 +45,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) := rte_kvargs.c INCS := rte_kvargs.h SYMLINK-$(CONFIG_RTE_LIBRTE_KVARGS)-include := $(INCS) -# this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += lib/librte_eal +# this lib needs +DEPDIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile index fa94163..9ebe16c 100644 --- a/lib/librte_lpm/Makefile +++ b/lib/librte_lpm/Makefile @@ -43,7 +43,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c # install this header file SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include := rte_lpm.h rte_lpm6.h -# this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_LPM) += lib/librte_eal lib/librte_malloc +# this lib needs +DEPDIRS-$(CONFIG_RTE_LIBRTE_LPM) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile index b25c0cc..dd984bd 100644 --- a/lib/librte_meter/Makefile +++ b/lib/librte_meter/Makefile @@ -48,6 +48,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_METER) := rte_meter.c SYMLINK-$(CONFIG_RTE_LIBRTE_METER)-include := rte_meter.h # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_METER) += lib/librte_eal +DEPDIRS-$(CONFIG_RTE_LIBRTE_METER) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile index cf8fde8..aae047a 100644 --- a/lib/librte_pipeline/Makefile +++ b/lib/librte_pipeline/Makefile @@ -48,6 +48,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_PIPELINE) := rte_pipeline.c SYMLINK-$(CONFIG_RTE_LIBRTE_PIPELINE)-include += rte_pipeline.h # this lib depends upon: +DEPDIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) := lib/librte_table DEPDIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += lib/librte_port diff --git a/lib/librte_pmd_af_packet/Makefile b/lib/librte_pmd_af_packet/Makefile index 6955e5c..a535563 100644 --- a/lib/librte_pmd_af_packet/Makefile +++ b/lib/librte_pmd_af_packet/Makefile @@ -52,9 +52,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += rte_eth_af_packet.c SYMLINK-y-include += rte_eth_af_packet.h # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_malloc DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_kvargs include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_bond/Makefile b/lib/librte_pmd_bond/Makefile index cdff126..8fa0b5c 100644 --- a/lib/librte_pmd_bond/Makefile +++ b/lib/librte_pmd_bond/Makefile @@ -58,10 +58,9 @@ 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_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_core 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 14bc4a2..dcda587 100644 --- a/lib/librte_pmd_e1000/Makefile +++ b/lib/librte_pmd_e1000/Makefile @@ -88,8 +88,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_EM_PMD) += em_ethdev.c SRCS-$(CONFIG_RTE_LIBRTE_EM_PMD) += em_rxtx.c # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += lib/librte_net include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile index a2a623f..b6519c7 100644 --- a/lib/librte_pmd_enic/Makefile +++ b/lib/librte_pmd_enic/Makefile @@ -59,9 +59,9 @@ SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_rq.c SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_rss.c # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_net DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_hash include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile index 98e4bdf..8ca76e7 100644 --- a/lib/librte_pmd_i40e/Makefile +++ b/lib/librte_pmd_i40e/Makefile @@ -94,8 +94,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_pf.c SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_net include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile index 3588047..7c08b0a 100644 --- a/lib/librte_pmd_ixgbe/Makefile +++ b/lib/librte_pmd_ixgbe/Makefile @@ -110,8 +110,8 @@ endif # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_net include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_pcap/Makefile b/lib/librte_pmd_pcap/Makefile index c5c214d..0997b8a 100644 --- a/lib/librte_pmd_pcap/Makefile +++ b/lib/librte_pmd_pcap/Makefile @@ -51,9 +51,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += rte_eth_pcap.c SYMLINK-y-include += # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += lib/librte_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += lib/librte_malloc DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += lib/librte_kvargs include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_ring/Makefile b/lib/librte_pmd_ring/Makefile index b57e421..7be9643 100644 --- a/lib/librte_pmd_ring/Makefile +++ b/lib/librte_pmd_ring/Makefile @@ -50,8 +50,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_RING) += rte_eth_ring.c 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_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_ether DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_kvargs include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_virtio/Makefile b/lib/librte_pmd_virtio/Makefile index 456095b..457a463 100644 --- a/lib/librte_pmd_virtio/Makefile +++ b/lib/librte_pmd_virtio/Makefile @@ -50,8 +50,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_net include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile index 6872c74..cc04bc3 100644 --- a/lib/librte_pmd_vmxnet3/Makefile +++ b/lib/librte_pmd_vmxnet3/Makefile @@ -73,8 +73,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3_rxtx.c SRCS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3_ethdev.c # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += lib/librte_net include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_xenvirt/Makefile b/lib/librte_pmd_xenvirt/Makefile index 01bfcaa..db79484 100644 --- a/lib/librte_pmd_xenvirt/Makefile +++ b/lib/librte_pmd_xenvirt/Makefile @@ -50,9 +50,9 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += rte_eth_xenvirt.c rte_mempool_gntalloc. SYMLINK-y-include += rte_eth_xenvirt.h # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_eal lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_net lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_net DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += lib/librte_cmdline include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_port/Makefile b/lib/librte_port/Makefile index 82b5192..e2f5114 100644 --- a/lib/librte_port/Makefile +++ b/lib/librte_port/Makefile @@ -67,11 +67,9 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_PORT)-include += rte_port_sched.h SYMLINK-$(CONFIG_RTE_LIBRTE_PORT)-include += rte_port_source_sink.h # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) := lib/librte_eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_mempool -DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) := lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_sched DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ip_frag include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_power/Makefile b/lib/librte_power/Makefile index d672a5a..a90afb5 100644 --- a/lib/librte_power/Makefile +++ b/lib/librte_power/Makefile @@ -44,6 +44,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_POWER) += rte_power_kvm_vm.c guest_channel.c SYMLINK-$(CONFIG_RTE_LIBRTE_POWER)-include := rte_power.h # this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_POWER) += lib/librte_eal +DEPDIRS-$(CONFIG_RTE_LIBRTE_POWER) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile index 1a25b21..613dc3e 100644 --- a/lib/librte_sched/Makefile +++ b/lib/librte_sched/Makefile @@ -50,7 +50,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_SCHED) += rte_sched.c rte_red.c rte_approx.c SYMLINK-$(CONFIG_RTE_LIBRTE_SCHED)-include := rte_sched.h rte_bitmap.h rte_sched_common.h rte_red.h rte_approx.h # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_SCHED) += lib/librte_mempool lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_SCHED) += lib/librte_net lib/librte_timer +DEPDIRS-$(CONFIG_RTE_LIBRTE_SCHED) += lib/librte_core +DEPDIRS-$(CONFIG_RTE_LIBRTE_SCHED) += lib/librte_net +DEPDIRS-$(CONFIG_RTE_LIBRTE_SCHED) += lib/librte_timer include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile index dd684cc..af849e6 100644 --- a/lib/librte_table/Makefile +++ b/lib/librte_table/Makefile @@ -68,10 +68,7 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_TABLE)-include += rte_table_array.h SYMLINK-$(CONFIG_RTE_LIBRTE_TABLE)-include += rte_table_stub.h # this lib depends upon: -DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) := lib/librte_eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_mbuf -DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_mempool -DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) := lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_port DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_lpm ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) diff --git a/lib/librte_timer/Makefile b/lib/librte_timer/Makefile index 07eb0c6..4698a3b 100644 --- a/lib/librte_timer/Makefile +++ b/lib/librte_timer/Makefile @@ -42,7 +42,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_TIMER) := rte_timer.c # install this header file SYMLINK-$(CONFIG_RTE_LIBRTE_TIMER)-include := rte_timer.h -# this lib needs eal -DEPDIRS-$(CONFIG_RTE_LIBRTE_TIMER) += lib/librte_eal +# this lib needs +DEPDIRS-$(CONFIG_RTE_LIBRTE_TIMER) += lib/librte_core include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile index c008d64..6176a28 100644 --- a/lib/librte_vhost/Makefile +++ b/lib/librte_vhost/Makefile @@ -43,8 +43,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := vhost-net-cdev.c virtio-net.c vhost_rxtx.c SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include += rte_virtio_net.h # dependencies -DEPDIRS-$(CONFIG_RTE_LIBRTE_VHOST) += lib/librte_eal +DEPDIRS-$(CONFIG_RTE_LIBRTE_VHOST) += lib/librte_core DEPDIRS-$(CONFIG_RTE_LIBRTE_VHOST) += lib/librte_ether -DEPDIRS-$(CONFIG_RTE_LIBRTE_VHOST) += lib/librte_mbuf include $(RTE_SDK)/mk/rte.lib.mk -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 5/8] lib: set LDLIBS for each library [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (3 preceding siblings ...) 2015-01-29 15:20 ` [PATCH 4/8] lib: update DEPDIRS variable Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 6/8] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy ` (4 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw When creating shared libraries, each library will be linked against their dependant libraries (LDLIBS). This patch sets the LDLIBS variable for each library. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- lib/librte_acl/Makefile | 1 + lib/librte_cfgfile/Makefile | 2 ++ lib/librte_cmdline/Makefile | 2 ++ lib/librte_distributor/Makefile | 2 ++ lib/librte_ether/Makefile | 2 ++ lib/librte_hash/Makefile | 2 ++ lib/librte_ip_frag/Makefile | 2 ++ lib/librte_ivshmem/Makefile | 2 ++ lib/librte_kni/Makefile | 2 ++ lib/librte_kvargs/Makefile | 2 ++ lib/librte_lpm/Makefile | 2 ++ lib/librte_meter/Makefile | 2 ++ lib/librte_pipeline/Makefile | 2 ++ lib/librte_pmd_af_packet/Makefile | 2 ++ lib/librte_pmd_bond/Makefile | 2 ++ lib/librte_pmd_e1000/Makefile | 2 ++ lib/librte_pmd_enic/Makefile | 2 ++ lib/librte_pmd_i40e/Makefile | 2 ++ lib/librte_pmd_ixgbe/Makefile | 2 ++ lib/librte_pmd_pcap/Makefile | 2 ++ lib/librte_pmd_ring/Makefile | 2 ++ lib/librte_pmd_virtio/Makefile | 1 + lib/librte_pmd_vmxnet3/Makefile | 2 ++ lib/librte_pmd_xenvirt/Makefile | 2 ++ lib/librte_port/Makefile | 2 ++ lib/librte_power/Makefile | 2 ++ lib/librte_sched/Makefile | 2 ++ lib/librte_table/Makefile | 3 +++ lib/librte_timer/Makefile | 2 ++ lib/librte_vhost/Makefile | 6 ++++-- 30 files changed, 61 insertions(+), 2 deletions(-) diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile index 926cb0d..c58e657 100644 --- a/lib/librte_acl/Makefile +++ b/lib/librte_acl/Makefile @@ -76,6 +76,7 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_ACL)-include += rte_acl_osdep_alone.h else # this lib needs DEPDIRS-$(CONFIG_RTE_LIBRTE_ACL) += lib/librte_core +LDLIBS += -lrte_core endif include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile index 2668230..5fee88d 100644 --- a/lib/librte_cfgfile/Makefile +++ b/lib/librte_cfgfile/Makefile @@ -39,6 +39,8 @@ LIB = librte_cfgfile.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core + # # all source are stored in SRCS-y # diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile index e72e11d..a4d7f1f 100644 --- a/lib/librte_cmdline/Makefile +++ b/lib/librte_cmdline/Makefile @@ -51,6 +51,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_parse_portlist.c CFLAGS += -D_GNU_SOURCE +LDLIBS += -lrte_core + # install includes INCS := cmdline.h cmdline_parse.h cmdline_parse_num.h cmdline_parse_ipaddr.h INCS += cmdline_parse_etheraddr.h cmdline_parse_string.h cmdline_rdline.h diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile index 01df4fa..41dbbbf 100644 --- a/lib/librte_distributor/Makefile +++ b/lib/librte_distributor/Makefile @@ -37,6 +37,8 @@ LIB = librte_distributor.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) +LDLIBS += -lrte_core + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile index 226313b..c017669 100644 --- a/lib/librte_ether/Makefile +++ b/lib/librte_ether/Makefile @@ -39,6 +39,8 @@ LIB = libethdev.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core + SRCS-y += rte_ethdev.c # diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile index 6bd8fe5..e607d44 100644 --- a/lib/librte_hash/Makefile +++ b/lib/librte_hash/Makefile @@ -37,6 +37,8 @@ LIB = librte_hash.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) +LDLIBS += -lrte_core + # 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 eedb94a..6dc967c 100644 --- a/lib/librte_ip_frag/Makefile +++ b/lib/librte_ip_frag/Makefile @@ -37,6 +37,8 @@ LIB = librte_ip_frag.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) +LDLIBS += -lrte_core -lethdev + #source files ifeq ($(CONFIG_RTE_MBUF_REFCNT),y) SRCS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += rte_ipv4_fragmentation.c diff --git a/lib/librte_ivshmem/Makefile b/lib/librte_ivshmem/Makefile index 4a6cca5..eec0901 100644 --- a/lib/librte_ivshmem/Makefile +++ b/lib/librte_ivshmem/Makefile @@ -36,6 +36,8 @@ LIB = librte_ivshmem.a CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 +LDLIBS += -lrte_core + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_IVSHMEM) := rte_ivshmem.c diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile index 0b9a261..149556c 100644 --- a/lib/librte_kni/Makefile +++ b/lib/librte_kni/Makefile @@ -36,6 +36,8 @@ LIB = librte_kni.a CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing +LDLIBS += -lrte_core -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 6564335..9a0c188 100644 --- a/lib/librte_kvargs/Makefile +++ b/lib/librte_kvargs/Makefile @@ -38,6 +38,8 @@ LIB = librte_kvargs.a CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 +LDLIBS += -lrte_core + # 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 9ebe16c..e0d01ce 100644 --- a/lib/librte_lpm/Makefile +++ b/lib/librte_lpm/Makefile @@ -37,6 +37,8 @@ LIB = librte_lpm.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) +LDLIBS += -lrte_core + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile index dd984bd..db961f9 100644 --- a/lib/librte_meter/Makefile +++ b/lib/librte_meter/Makefile @@ -39,6 +39,8 @@ LIB = librte_meter.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core + # # all source are stored in SRCS-y # diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile index aae047a..8a3eed6 100644 --- a/lib/librte_pipeline/Makefile +++ b/lib/librte_pipeline/Makefile @@ -39,6 +39,8 @@ LIB = librte_pipeline.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lrte_table -lrte_port + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_af_packet/Makefile b/lib/librte_pmd_af_packet/Makefile index a535563..7ce4bc3 100644 --- a/lib/librte_pmd_af_packet/Makefile +++ b/lib/librte_pmd_af_packet/Makefile @@ -41,6 +41,8 @@ LIB = librte_pmd_af_packet.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -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 8fa0b5c..7de413f 100644 --- a/lib/librte_pmd_bond/Makefile +++ b/lib/librte_pmd_bond/Makefile @@ -39,6 +39,8 @@ LIB = librte_pmd_bond.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lethdev -lrte_kvargs -lrte_cmdline + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_e1000/Makefile b/lib/librte_pmd_e1000/Makefile index dcda587..d400df9 100644 --- a/lib/librte_pmd_e1000/Makefile +++ b/lib/librte_pmd_e1000/Makefile @@ -61,6 +61,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER)) VPATH += $(RTE_SDK)/lib/librte_pmd_e1000/e1000 +LDLIBS += -lrte_core -lethdev + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile index b6519c7..14c5a73 100644 --- a/lib/librte_pmd_enic/Makefile +++ b/lib/librte_pmd_enic/Makefile @@ -44,6 +44,8 @@ CFLAGS += $(WERROR_FLAGS) -Wno-strict-aliasing VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src +LDLIBS += -lrte_core -lethdev -lrte_hash + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile index 8ca76e7..9eac9a4 100644 --- a/lib/librte_pmd_i40e/Makefile +++ b/lib/librte_pmd_i40e/Makefile @@ -76,6 +76,8 @@ $(foreach obj, $(OBJS_BASE_DRIVER), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER)) VPATH += $(RTE_SDK)/lib/librte_pmd_i40e/i40e +LDLIBS += -lrte_core -lethdev + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile index 7c08b0a..2c8248a 100644 --- a/lib/librte_pmd_ixgbe/Makefile +++ b/lib/librte_pmd_ixgbe/Makefile @@ -82,6 +82,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER)) VPATH += $(RTE_SDK)/lib/librte_pmd_ixgbe/ixgbe +LDLIBS += -lrte_core -lethdev + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_pcap/Makefile b/lib/librte_pmd_pcap/Makefile index 0997b8a..f58a5dc 100644 --- a/lib/librte_pmd_pcap/Makefile +++ b/lib/librte_pmd_pcap/Makefile @@ -40,6 +40,8 @@ LIB = librte_pmd_pcap.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -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 7be9643..1418957 100644 --- a/lib/librte_pmd_ring/Makefile +++ b/lib/librte_pmd_ring/Makefile @@ -39,6 +39,8 @@ LIB = librte_pmd_ring.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lethdev -lrte_kvargs + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_virtio/Makefile b/lib/librte_pmd_virtio/Makefile index 457a463..a00077d 100644 --- a/lib/librte_pmd_virtio/Makefile +++ b/lib/librte_pmd_virtio/Makefile @@ -39,6 +39,7 @@ LIB = librte_pmd_virtio_uio.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lethdev # # all source are stored in SRCS-y diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile index cc04bc3..a7a4eed 100644 --- a/lib/librte_pmd_vmxnet3/Makefile +++ b/lib/librte_pmd_vmxnet3/Makefile @@ -66,6 +66,8 @@ endif VPATH += $(RTE_SDK)/lib/librte_pmd_vmxnet3/vmxnet3 +LDLIBS += -lrte_core -lethdev + # # all source are stored in SRCS-y # diff --git a/lib/librte_pmd_xenvirt/Makefile b/lib/librte_pmd_xenvirt/Makefile index db79484..0bfb7db 100644 --- a/lib/librte_pmd_xenvirt/Makefile +++ b/lib/librte_pmd_xenvirt/Makefile @@ -39,6 +39,8 @@ LIB = librte_pmd_xenvirt.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lethdev -rte_cmdline -xenstore + # # all source are stored in SRCS-y # diff --git a/lib/librte_port/Makefile b/lib/librte_port/Makefile index e2f5114..032fe59 100644 --- a/lib/librte_port/Makefile +++ b/lib/librte_port/Makefile @@ -39,6 +39,8 @@ LIB = librte_port.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lethdev -lrte_sched -lrte_ip_frag + # # all source are stored in SRCS-y # diff --git a/lib/librte_power/Makefile b/lib/librte_power/Makefile index a90afb5..41d8ba2 100644 --- a/lib/librte_power/Makefile +++ b/lib/librte_power/Makefile @@ -36,6 +36,8 @@ LIB = librte_power.a CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing +LDLIBS += -lrte_core + # 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_sched/Makefile b/lib/librte_sched/Makefile index 613dc3e..b998ab6 100644 --- a/lib/librte_sched/Makefile +++ b/lib/librte_sched/Makefile @@ -41,6 +41,8 @@ CFLAGS += $(WERROR_FLAGS) CFLAGS_rte_red.o := -D_GNU_SOURCE +LDLIBS += -lrte_core -lrte_timer + # # all source are stored in SRCS-y # diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile index af849e6..3be52ae 100644 --- a/lib/librte_table/Makefile +++ b/lib/librte_table/Makefile @@ -39,6 +39,8 @@ LIB = librte_table.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_core -lrte_port -lrte_lpm -lrte_hash + # # all source are stored in SRCS-y # @@ -73,6 +75,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 4698a3b..ff4c057 100644 --- a/lib/librte_timer/Makefile +++ b/lib/librte_timer/Makefile @@ -36,6 +36,8 @@ LIB = librte_timer.a CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 +LDLIBS += -lrte_core + # 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 6176a28..41c4f9f 100644 --- a/lib/librte_vhost/Makefile +++ b/lib/librte_vhost/Makefile @@ -34,8 +34,10 @@ include $(RTE_SDK)/mk/rte.vars.mk # library name LIB = librte_vhost.a -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64 -lfuse -LDFLAGS += -lfuse +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64 + +LDLIBS += -lrte_core -lethdev -lfuse + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := vhost-net-cdev.c virtio-net.c vhost_rxtx.c -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 6/8] mk: use LDLIBS when linking shared libraries [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (4 preceding siblings ...) 2015-01-29 15:20 ` [PATCH 5/8] lib: set LDLIBS for each library Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 7/8] mk: update LDLIBS for app building Sergio Gonzalez Monroy ` (3 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw This patch mainly makes use of the LDLIBS variable when linking shared libraries, setting proper DT_NEEDED entries. This patch also fix a few nits like syntax highlighting, the command string (O_TO_S_STR) used for linking shared libraries and the displayed of dependencies when debugging is enable (D). Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- 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 7c99fd1..559c76a 100644 --- a/mk/rte.lib.mk +++ b/mk/rte.lib.mk @@ -59,16 +59,19 @@ build: _postbuild exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1)))) +_LDLIBS := -z defs --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; \ @@ -76,9 +79,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) -o $(LIB) -O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight +O_TO_S = $(LD) $(_CPU_LDFLAGS) -L $(RTE_OUTPUT)/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) && \ @@ -93,7 +98,7 @@ ifeq ($(RTE_BUILD_SHARED_LIB),y) $(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_S_STR))) " ; \ echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \ @@ -108,7 +113,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 related [flat|nested] 63+ messages in thread
* [PATCH 7/8] mk: update LDLIBS for app building [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (5 preceding siblings ...) 2015-01-29 15:20 ` [PATCH 6/8] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 15:20 ` [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy ` (2 subsequent siblings) 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw This patch does: - Update the app building command to link against librte_core. - Set --start-group/--end-group and --whole-archive/--no-whole-archive flags only when linking against static DPDK libs. - Set --as-needed when linking against shared DPDK libs. - Link against EXECENV_LIBS always with --as-needed flag. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- mk/rte.app.mk | 45 ++++++++++++++------------------------------- 1 file changed, 14 insertions(+), 31 deletions(-) diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 4c70743..2c9a856 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -59,7 +59,14 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib # ifeq ($(NO_AUTOLIBS),) -LDLIBS += --whole-archive +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) +LDLIBS += --as-needed +else +LDLIBS += --no-as-needed +LDLIBS += --start-group +endif + +LDLIBS += -lrte_core ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) LDLIBS += -lrte_distributor @@ -124,19 +131,14 @@ LDLIBS += -lpcap endif ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y) +LDLIBS += -lrte_vhost LDLIBS += -lfuse endif -LDLIBS += --start-group - ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y) LDLIBS += -lrte_kvargs endif -ifeq ($(CONFIG_RTE_LIBRTE_MBUF),y) -LDLIBS += -lrte_mbuf -endif - ifeq ($(CONFIG_RTE_LIBRTE_IP_FRAG),y) LDLIBS += -lrte_ip_frag endif @@ -145,22 +147,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 @@ -180,6 +166,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 @@ -189,10 +176,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VIRTIO_PMD),y) LDLIBS += -lrte_pmd_virtio_uio endif -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) -LDLIBS += -lrte_vhost -endif - ifeq ($(CONFIG_RTE_LIBRTE_ENIC_PMD),y) LDLIBS += -lrte_pmd_enic endif @@ -221,14 +204,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 related [flat|nested] 63+ messages in thread
* [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (6 preceding siblings ...) 2015-01-29 15:20 ` [PATCH 7/8] mk: update LDLIBS for app building Sergio Gonzalez Monroy @ 2015-01-29 15:20 ` Sergio Gonzalez Monroy 2015-01-29 16:38 ` [PATCH 0/8] Improve build process Neil Horman 2015-03-12 16:27 ` [PATCH v2 0/4] " Sergio Gonzalez Monroy 9 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw) To: dev-VfR2kkLFssw We need to add -lpthread to EXECENV_LDLIBS because we are not passing -pthread flags in EXECENV_CFLAGS to GCC when linking apps/ Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- mk/exec-env/linuxapp/rte.vars.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mk/exec-env/linuxapp/rte.vars.mk b/mk/exec-env/linuxapp/rte.vars.mk index e5af318..dc01ce9 100644 --- a/mk/exec-env/linuxapp/rte.vars.mk +++ b/mk/exec-env/linuxapp/rte.vars.mk @@ -49,6 +49,8 @@ endif EXECENV_LDFLAGS = --no-as-needed EXECENV_LDLIBS = -lrt -lm +EXECENV_LDLIBS += -lpthread + EXECENV_ASFLAGS = ifeq ($(RTE_BUILD_SHARED_LIB),y) -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH 0/8] Improve build process [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (7 preceding siblings ...) 2015-01-29 15:20 ` [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy @ 2015-01-29 16:38 ` Neil Horman [not found] ` <20150129163859.GE1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 2015-03-12 16:27 ` [PATCH v2 0/4] " Sergio Gonzalez Monroy 9 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-01-29 16:38 UTC (permalink / raw) To: Sergio Gonzalez Monroy; +Cc: dev-VfR2kkLFssw On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > This patch series improves the DPDK build system mostly for shared > libraries (and a few nits for static libraries) with the following goals: > - Create a library containing core DPDK libraries (librte_eal, > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > The idea of core libraries is to group those libraries that are > always required (and have interdependencies) for any DPDK application. > - Remove config option to build a combined library. > - For shared libraries, explicitly link against dependant > libraries (adding entries to DT_NEEDED). > - Update app linking flags for static/shared DPDK libs. > > Sergio Gonzalez Monroy (8): > mk: remove combined library and related options > core: create new librte_core > mk: new corelib makefile > lib: update DEPDIRS variable > lib: set LDLIBS for each library > mk: use LDLIBS when linking shared libraries > mk: update LDLIBS for app building > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > config/common_bsdapp | 6 -- > config/common_linuxapp | 6 -- > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > lib/Makefile | 1 - > lib/librte_acl/Makefile | 5 +- > lib/librte_cfgfile/Makefile | 4 +- > lib/librte_cmdline/Makefile | 6 +- > lib/librte_core/Makefile | 45 +++++++++++++ > lib/librte_distributor/Makefile | 5 +- > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > lib/librte_ether/Makefile | 4 +- > lib/librte_hash/Makefile | 4 +- > lib/librte_ip_frag/Makefile | 6 +- > lib/librte_ivshmem/Makefile | 4 +- > lib/librte_kni/Makefile | 6 +- > lib/librte_kvargs/Makefile | 6 +- > lib/librte_lpm/Makefile | 6 +- > lib/librte_malloc/Makefile | 2 +- > lib/librte_mbuf/Makefile | 2 +- > lib/librte_mempool/Makefile | 2 +- > lib/librte_meter/Makefile | 4 +- > lib/librte_pipeline/Makefile | 3 + > lib/librte_pmd_af_packet/Makefile | 5 +- > lib/librte_pmd_bond/Makefile | 7 +- > lib/librte_pmd_e1000/Makefile | 8 ++- > lib/librte_pmd_enic/Makefile | 8 ++- > lib/librte_pmd_i40e/Makefile | 8 ++- > lib/librte_pmd_ixgbe/Makefile | 8 ++- > lib/librte_pmd_pcap/Makefile | 5 +- > lib/librte_pmd_ring/Makefile | 6 +- > lib/librte_pmd_virtio/Makefile | 7 +- > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > lib/librte_pmd_xenvirt/Makefile | 8 ++- > lib/librte_port/Makefile | 8 +-- > lib/librte_power/Makefile | 4 +- > lib/librte_ring/Makefile | 2 +- > lib/librte_sched/Makefile | 7 +- > lib/librte_table/Makefile | 8 +-- > lib/librte_timer/Makefile | 6 +- > lib/librte_vhost/Makefile | 9 +-- > mk/exec-env/linuxapp/rte.vars.mk | 2 + > mk/rte.app.mk | 53 ++++----------- > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > mk/rte.lib.mk | 49 +++----------- > mk/rte.sdkbuild.mk | 3 - > mk/rte.sharelib.mk | 101 ---------------------------- > mk/rte.vars.mk | 9 --- > 48 files changed, 276 insertions(+), 282 deletions(-) > create mode 100644 lib/librte_core/Makefile > create mode 100644 mk/rte.corelib.mk > delete mode 100644 mk/rte.sharelib.mk > > -- > 1.9.3 > > Something occured to me thinking about this patch set. I noticed recently that different rules are used to build the shared combined lib from the individual shared objects. The implication here is that linker options specified in individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI versioning script) get ignored, which is bad. Any other file specific linker options (like <file>_LDFLAGS specified in individual library makefiles are getting dropped for the combined lib. It seems like it would be better if the combined libs were manufactured as linker scripts themselves (textfiles that used linker directives to include individual libraries under the covers (see /lib64/libc.so for an example). The disadvantage of such an approach are fairly minimal. With such a combined library, you still need to install individual libraries, but for applications that wish to link and run against a single dpdk library will still work just as they currently do, you can link to just a single library. The advantage is clear however. By following a linker script aproach, objects build as separate libraries are built exactly the same way, using the same rules with the same options. It reduces the dpdk build environment size and complexity, and reduces the opportunity for bugs to creep in from forgetting to add build options to multiple locations. It also provides a more granular approach for grouping files. Creating a dpdk core library becomes a matter of creating a one line linker script named libdpdk_core.so, rather than re-arraning sections of the build system. Thoughts? Neil ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150129163859.GE1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150129163859.GE1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-01-29 17:02 ` Thomas Monjalon 2015-01-29 17:04 ` Gonzalez Monroy, Sergio 1 sibling, 0 replies; 63+ messages in thread From: Thomas Monjalon @ 2015-01-29 17:02 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw 2015-01-29 11:38, Neil Horman: > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > The idea of core libraries is to group those libraries that are > > always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > > libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > Something occured to me thinking about this patch set. I noticed recently that > different rules are used to build the shared combined lib from the individual > shared objects. The implication here is that linker options specified in > individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI > versioning script) get ignored, which is bad. Any other file specific linker > options (like <file>_LDFLAGS specified in individual library makefiles are > getting dropped for the combined lib. > > It seems like it would be better if the combined libs were manufactured as > linker scripts themselves (textfiles that used linker directives to include > individual libraries under the covers (see /lib64/libc.so for an example). > > The disadvantage of such an approach are fairly minimal. With such a combined > library, you still need to install individual libraries, but for applications > that wish to link and run against a single dpdk library will still work just as > they currently do, you can link to just a single library. > > The advantage is clear however. By following a linker script aproach, objects > build as separate libraries are built exactly the same way, using the same rules > with the same options. It reduces the dpdk build environment size and > complexity, and reduces the opportunity for bugs to creep in from forgetting to > add build options to multiple locations. It also provides a more granular > approach for grouping files. Creating a dpdk core library becomes a matter of > creating a one line linker script named libdpdk_core.so, rather than re-arraning > sections of the build system. > > Thoughts? Neil, it seems to be a good idea. I like the idea of making things simpler ;) -- Thomas ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/8] Improve build process [not found] ` <20150129163859.GE1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 2015-01-29 17:02 ` Thomas Monjalon @ 2015-01-29 17:04 ` Gonzalez Monroy, Sergio [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F43D9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 1 sibling, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-01-29 17:04 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > Sent: Thursday, January 29, 2015 4:39 PM > To: Gonzalez Monroy, Sergio > Cc: dev-VfR2kkLFssw@public.gmane.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > The idea of core libraries is to group those libraries that are > > always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > > libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > config/common_bsdapp | 6 -- > > config/common_linuxapp | 6 -- > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > lib/Makefile | 1 - > > lib/librte_acl/Makefile | 5 +- > > lib/librte_cfgfile/Makefile | 4 +- > > lib/librte_cmdline/Makefile | 6 +- > > lib/librte_core/Makefile | 45 +++++++++++++ > > lib/librte_distributor/Makefile | 5 +- > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > lib/librte_ether/Makefile | 4 +- > > lib/librte_hash/Makefile | 4 +- > > lib/librte_ip_frag/Makefile | 6 +- > > lib/librte_ivshmem/Makefile | 4 +- > > lib/librte_kni/Makefile | 6 +- > > lib/librte_kvargs/Makefile | 6 +- > > lib/librte_lpm/Makefile | 6 +- > > lib/librte_malloc/Makefile | 2 +- > > lib/librte_mbuf/Makefile | 2 +- > > lib/librte_mempool/Makefile | 2 +- > > lib/librte_meter/Makefile | 4 +- > > lib/librte_pipeline/Makefile | 3 + > > lib/librte_pmd_af_packet/Makefile | 5 +- > > lib/librte_pmd_bond/Makefile | 7 +- > > lib/librte_pmd_e1000/Makefile | 8 ++- > > lib/librte_pmd_enic/Makefile | 8 ++- > > lib/librte_pmd_i40e/Makefile | 8 ++- > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > lib/librte_pmd_pcap/Makefile | 5 +- > > lib/librte_pmd_ring/Makefile | 6 +- > > lib/librte_pmd_virtio/Makefile | 7 +- > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > lib/librte_port/Makefile | 8 +-- > > lib/librte_power/Makefile | 4 +- > > lib/librte_ring/Makefile | 2 +- > > lib/librte_sched/Makefile | 7 +- > > lib/librte_table/Makefile | 8 +-- > > lib/librte_timer/Makefile | 6 +- > > lib/librte_vhost/Makefile | 9 +-- > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > mk/rte.app.mk | 53 ++++----------- > > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > > mk/rte.lib.mk | 49 +++----------- > > mk/rte.sdkbuild.mk | 3 - > > mk/rte.sharelib.mk | 101 ---------------------------- > > mk/rte.vars.mk | 9 --- > > 48 files changed, 276 insertions(+), 282 deletions(-) create mode > > 100644 lib/librte_core/Makefile create mode 100644 mk/rte.corelib.mk > > delete mode 100644 mk/rte.sharelib.mk > > > > -- > > 1.9.3 > > > > > Something occured to me thinking about this patch set. I noticed recently > that different rules are used to build the shared combined lib from the > individual shared objects. The implication here is that linker options specified > in individual make files (like the LIBABIVER and EXPORT_MAP options in my > ABI versioning script) get ignored, which is bad. Any other file specific linker > options (like <file>_LDFLAGS specified in individual library makefiles are > getting dropped for the combined lib. > > It seems like it would be better if the combined libs were manufactured as > linker scripts themselves (textfiles that used linker directives to include > individual libraries under the covers (see /lib64/libc.so for an example). > > The disadvantage of such an approach are fairly minimal. With such a > combined library, you still need to install individual libraries, but for > applications that wish to link and run against a single dpdk library will still work > just as they currently do, you can link to just a single library. > > The advantage is clear however. By following a linker script aproach, objects > build as separate libraries are built exactly the same way, using the same > rules with the same options. It reduces the dpdk build environment size and > complexity, and reduces the opportunity for bugs to creep in from forgetting > to add build options to multiple locations. It also provides a more granular > approach for grouping files. Creating a dpdk core library becomes a matter of > creating a one line linker script named libdpdk_core.so, rather than re- > arraning sections of the build system. > > Thoughts? > Neil > Hi Neil, I think that is a very interesting approach. I have tried to do something similar in this patch by removing rte.sharelib.mk and just having rte.lib.mk to do the linking, leaving as you suggest a single file to modify anything related to building libs. I do think however that your proposal is an improvement over the current patch. So basically we want: - get rid of rte.corelib.mk - generate librte_core.so linker script grouping core libs - we do not modify DEPDIR variables - when setting LDLIBS to each lib, we do specify -lrte_core, right? Regards, Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <91383E96CE459D47BCE92EFBF5CE73B004F43D9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F43D9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-01-29 19:45 ` Neil Horman [not found] ` <20150129194539.GG1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-01-29 19:45 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Thu, Jan 29, 2015 at 05:04:20PM +0000, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > Sent: Thursday, January 29, 2015 4:39 PM > > To: Gonzalez Monroy, Sergio > > Cc: dev-VfR2kkLFssw@public.gmane.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > > This patch series improves the DPDK build system mostly for shared > > > libraries (and a few nits for static libraries) with the following goals: > > > - Create a library containing core DPDK libraries (librte_eal, > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > The idea of core libraries is to group those libraries that are > > > always required (and have interdependencies) for any DPDK application. > > > - Remove config option to build a combined library. > > > - For shared libraries, explicitly link against dependant > > > libraries (adding entries to DT_NEEDED). > > > - Update app linking flags for static/shared DPDK libs. > > > > > > Sergio Gonzalez Monroy (8): > > > mk: remove combined library and related options > > > core: create new librte_core > > > mk: new corelib makefile > > > lib: update DEPDIRS variable > > > lib: set LDLIBS for each library > > > mk: use LDLIBS when linking shared libraries > > > mk: update LDLIBS for app building > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > config/common_bsdapp | 6 -- > > > config/common_linuxapp | 6 -- > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > lib/Makefile | 1 - > > > lib/librte_acl/Makefile | 5 +- > > > lib/librte_cfgfile/Makefile | 4 +- > > > lib/librte_cmdline/Makefile | 6 +- > > > lib/librte_core/Makefile | 45 +++++++++++++ > > > lib/librte_distributor/Makefile | 5 +- > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > > lib/librte_ether/Makefile | 4 +- > > > lib/librte_hash/Makefile | 4 +- > > > lib/librte_ip_frag/Makefile | 6 +- > > > lib/librte_ivshmem/Makefile | 4 +- > > > lib/librte_kni/Makefile | 6 +- > > > lib/librte_kvargs/Makefile | 6 +- > > > lib/librte_lpm/Makefile | 6 +- > > > lib/librte_malloc/Makefile | 2 +- > > > lib/librte_mbuf/Makefile | 2 +- > > > lib/librte_mempool/Makefile | 2 +- > > > lib/librte_meter/Makefile | 4 +- > > > lib/librte_pipeline/Makefile | 3 + > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > lib/librte_pmd_bond/Makefile | 7 +- > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > lib/librte_pmd_enic/Makefile | 8 ++- > > > lib/librte_pmd_i40e/Makefile | 8 ++- > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > lib/librte_pmd_pcap/Makefile | 5 +- > > > lib/librte_pmd_ring/Makefile | 6 +- > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > lib/librte_port/Makefile | 8 +-- > > > lib/librte_power/Makefile | 4 +- > > > lib/librte_ring/Makefile | 2 +- > > > lib/librte_sched/Makefile | 7 +- > > > lib/librte_table/Makefile | 8 +-- > > > lib/librte_timer/Makefile | 6 +- > > > lib/librte_vhost/Makefile | 9 +-- > > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > > mk/rte.app.mk | 53 ++++----------- > > > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > > > mk/rte.lib.mk | 49 +++----------- > > > mk/rte.sdkbuild.mk | 3 - > > > mk/rte.sharelib.mk | 101 ---------------------------- > > > mk/rte.vars.mk | 9 --- > > > 48 files changed, 276 insertions(+), 282 deletions(-) create mode > > > 100644 lib/librte_core/Makefile create mode 100644 mk/rte.corelib.mk > > > delete mode 100644 mk/rte.sharelib.mk > > > > > > -- > > > 1.9.3 > > > > > > > > Something occured to me thinking about this patch set. I noticed recently > > that different rules are used to build the shared combined lib from the > > individual shared objects. The implication here is that linker options specified > > in individual make files (like the LIBABIVER and EXPORT_MAP options in my > > ABI versioning script) get ignored, which is bad. Any other file specific linker > > options (like <file>_LDFLAGS specified in individual library makefiles are > > getting dropped for the combined lib. > > > > It seems like it would be better if the combined libs were manufactured as > > linker scripts themselves (textfiles that used linker directives to include > > individual libraries under the covers (see /lib64/libc.so for an example). > > > > The disadvantage of such an approach are fairly minimal. With such a > > combined library, you still need to install individual libraries, but for > > applications that wish to link and run against a single dpdk library will still work > > just as they currently do, you can link to just a single library. > > > > The advantage is clear however. By following a linker script aproach, objects > > build as separate libraries are built exactly the same way, using the same > > rules with the same options. It reduces the dpdk build environment size and > > complexity, and reduces the opportunity for bugs to creep in from forgetting > > to add build options to multiple locations. It also provides a more granular > > approach for grouping files. Creating a dpdk core library becomes a matter of > > creating a one line linker script named libdpdk_core.so, rather than re- > > arraning sections of the build system. > > > > Thoughts? > > Neil > > > Hi Neil, > > I think that is a very interesting approach. > I have tried to do something similar in this patch by removing rte.sharelib.mk and > just having rte.lib.mk to do the linking, leaving as you suggest a single file to > modify anything related to building libs. > > I do think however that your proposal is an improvement over the current patch. > > So basically we want: > - get rid of rte.corelib.mk > - generate librte_core.so linker script grouping core libs > - we do not modify DEPDIR variables > - when setting LDLIBS to each lib, we do specify -lrte_core, right? > Exactly, and librte_core.so is really just a text file containing the following line : INPUT(-lrte_malloc -lrte_mbuf -lrte_eal ....) Adding in whatever libraries you want librte_core to consist of. Truthfully, you could almost get rid of the COMBINE_LIBS option entirely, and just create this file statically if you wanted to (not sure thats the best approach, but its definately do-able). Regards Neil ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150129194539.GG1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150129194539.GG1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-01-30 13:39 ` Gonzalez Monroy, Sergio [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F453D7-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-01-30 13:39 UTC (permalink / raw) To: Neil Horman, Thomas Monjalon; +Cc: dev-VfR2kkLFssw > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > Sent: Thursday, January 29, 2015 7:46 PM > To: Gonzalez Monroy, Sergio > Cc: dev-VfR2kkLFssw@public.gmane.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > On Thu, Jan 29, 2015 at 05:04:20PM +0000, Gonzalez Monroy, Sergio wrote: > > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > > Sent: Thursday, January 29, 2015 4:39 PM > > > To: Gonzalez Monroy, Sergio > > > Cc: dev-VfR2kkLFssw@public.gmane.org > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy > wrote: > > > > This patch series improves the DPDK build system mostly for shared > > > > libraries (and a few nits for static libraries) with the following goals: > > > > - Create a library containing core DPDK libraries (librte_eal, > > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > > The idea of core libraries is to group those libraries that are > > > > always required (and have interdependencies) for any DPDK > application. > > > > - Remove config option to build a combined library. > > > > - For shared libraries, explicitly link against dependant > > > > libraries (adding entries to DT_NEEDED). > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > Sergio Gonzalez Monroy (8): > > > > mk: remove combined library and related options > > > > core: create new librte_core > > > > mk: new corelib makefile > > > > lib: update DEPDIRS variable > > > > lib: set LDLIBS for each library > > > > mk: use LDLIBS when linking shared libraries > > > > mk: update LDLIBS for app building > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > config/common_bsdapp | 6 -- > > > > config/common_linuxapp | 6 -- > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > lib/Makefile | 1 - > > > > lib/librte_acl/Makefile | 5 +- > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > lib/librte_cmdline/Makefile | 6 +- > > > > lib/librte_core/Makefile | 45 +++++++++++++ > > > > lib/librte_distributor/Makefile | 5 +- > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > > > lib/librte_ether/Makefile | 4 +- > > > > lib/librte_hash/Makefile | 4 +- > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > lib/librte_kni/Makefile | 6 +- > > > > lib/librte_kvargs/Makefile | 6 +- > > > > lib/librte_lpm/Makefile | 6 +- > > > > lib/librte_malloc/Makefile | 2 +- > > > > lib/librte_mbuf/Makefile | 2 +- > > > > lib/librte_mempool/Makefile | 2 +- > > > > lib/librte_meter/Makefile | 4 +- > > > > lib/librte_pipeline/Makefile | 3 + > > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > > lib/librte_pmd_bond/Makefile | 7 +- > > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > > lib/librte_pmd_enic/Makefile | 8 ++- > > > > lib/librte_pmd_i40e/Makefile | 8 ++- > > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > > lib/librte_pmd_pcap/Makefile | 5 +- > > > > lib/librte_pmd_ring/Makefile | 6 +- > > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > > lib/librte_port/Makefile | 8 +-- > > > > lib/librte_power/Makefile | 4 +- > > > > lib/librte_ring/Makefile | 2 +- > > > > lib/librte_sched/Makefile | 7 +- > > > > lib/librte_table/Makefile | 8 +-- > > > > lib/librte_timer/Makefile | 6 +- > > > > lib/librte_vhost/Makefile | 9 +-- > > > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > > > mk/rte.app.mk | 53 ++++----------- > > > > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > > > > mk/rte.lib.mk | 49 +++----------- > > > > mk/rte.sdkbuild.mk | 3 - > > > > mk/rte.sharelib.mk | 101 ---------------------------- > > > > mk/rte.vars.mk | 9 --- > > > > 48 files changed, 276 insertions(+), 282 deletions(-) create > > > > mode > > > > 100644 lib/librte_core/Makefile create mode 100644 > > > > mk/rte.corelib.mk delete mode 100644 mk/rte.sharelib.mk > > > > > > > > -- > > > > 1.9.3 > > > > > > > > > > > Something occured to me thinking about this patch set. I noticed > > > recently that different rules are used to build the shared combined > > > lib from the individual shared objects. The implication here is > > > that linker options specified in individual make files (like the > > > LIBABIVER and EXPORT_MAP options in my ABI versioning script) get > > > ignored, which is bad. Any other file specific linker options (like > > > <file>_LDFLAGS specified in individual library makefiles are getting > dropped for the combined lib. > > > > > > It seems like it would be better if the combined libs were > > > manufactured as linker scripts themselves (textfiles that used > > > linker directives to include individual libraries under the covers (see > /lib64/libc.so for an example). > > > > > > The disadvantage of such an approach are fairly minimal. With such > > > a combined library, you still need to install individual libraries, > > > but for applications that wish to link and run against a single dpdk > > > library will still work just as they currently do, you can link to just a single > library. > > > > > > The advantage is clear however. By following a linker script > > > aproach, objects build as separate libraries are built exactly the > > > same way, using the same rules with the same options. It reduces > > > the dpdk build environment size and complexity, and reduces the > > > opportunity for bugs to creep in from forgetting to add build > > > options to multiple locations. It also provides a more granular > > > approach for grouping files. Creating a dpdk core library becomes a > > > matter of creating a one line linker script named libdpdk_core.so, rather > than re- arraning sections of the build system. > > > > > > Thoughts? > > > Neil > > > > > Hi Neil, > > > > I think that is a very interesting approach. > > I have tried to do something similar in this patch by removing > > rte.sharelib.mk and just having rte.lib.mk to do the linking, leaving > > as you suggest a single file to modify anything related to building libs. > > > > I do think however that your proposal is an improvement over the current > patch. > > > > So basically we want: > > - get rid of rte.corelib.mk > > - generate librte_core.so linker script grouping core libs > > - we do not modify DEPDIR variables > > - when setting LDLIBS to each lib, we do specify -lrte_core, right? > > > Exactly, and librte_core.so is really just a text file containing the following line > : > INPUT(-lrte_malloc -lrte_mbuf -lrte_eal ....) > > Adding in whatever libraries you want librte_core to consist of. Truthfully, > you could almost get rid of the COMBINE_LIBS option entirely, and just > create this file statically if you wanted to (not sure thats the best approach, > but its definately do-able). > Hi Neil, Actually, the first patch series does get rid of COMBINE_LIBS entirely. So as I was looking into this, by using this approach we do not resolve the interdependencies issue of the core libraries. We would effectively leave all core libraries (or at least EAL) without proper DT_NEEDED entries. Thoughts? Regards, Sergio > Regards > Neil > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <91383E96CE459D47BCE92EFBF5CE73B004F453D7-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F453D7-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-01-30 14:05 ` Neil Horman [not found] ` <20150130140507.GA2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-01-30 14:05 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Fri, Jan 30, 2015 at 01:39:28PM +0000, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > Sent: Thursday, January 29, 2015 7:46 PM > > To: Gonzalez Monroy, Sergio > > Cc: dev-VfR2kkLFssw@public.gmane.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Thu, Jan 29, 2015 at 05:04:20PM +0000, Gonzalez Monroy, Sergio wrote: > > > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > > > Sent: Thursday, January 29, 2015 4:39 PM > > > > To: Gonzalez Monroy, Sergio > > > > Cc: dev-VfR2kkLFssw@public.gmane.org > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy > > wrote: > > > > > This patch series improves the DPDK build system mostly for shared > > > > > libraries (and a few nits for static libraries) with the following goals: > > > > > - Create a library containing core DPDK libraries (librte_eal, > > > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > > > The idea of core libraries is to group those libraries that are > > > > > always required (and have interdependencies) for any DPDK > > application. > > > > > - Remove config option to build a combined library. > > > > > - For shared libraries, explicitly link against dependant > > > > > libraries (adding entries to DT_NEEDED). > > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > > > Sergio Gonzalez Monroy (8): > > > > > mk: remove combined library and related options > > > > > core: create new librte_core > > > > > mk: new corelib makefile > > > > > lib: update DEPDIRS variable > > > > > lib: set LDLIBS for each library > > > > > mk: use LDLIBS when linking shared libraries > > > > > mk: update LDLIBS for app building > > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > > > config/common_bsdapp | 6 -- > > > > > config/common_linuxapp | 6 -- > > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > > lib/Makefile | 1 - > > > > > lib/librte_acl/Makefile | 5 +- > > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > > lib/librte_cmdline/Makefile | 6 +- > > > > > lib/librte_core/Makefile | 45 +++++++++++++ > > > > > lib/librte_distributor/Makefile | 5 +- > > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > > > > lib/librte_ether/Makefile | 4 +- > > > > > lib/librte_hash/Makefile | 4 +- > > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > > lib/librte_kni/Makefile | 6 +- > > > > > lib/librte_kvargs/Makefile | 6 +- > > > > > lib/librte_lpm/Makefile | 6 +- > > > > > lib/librte_malloc/Makefile | 2 +- > > > > > lib/librte_mbuf/Makefile | 2 +- > > > > > lib/librte_mempool/Makefile | 2 +- > > > > > lib/librte_meter/Makefile | 4 +- > > > > > lib/librte_pipeline/Makefile | 3 + > > > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > > > lib/librte_pmd_bond/Makefile | 7 +- > > > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > > > lib/librte_pmd_enic/Makefile | 8 ++- > > > > > lib/librte_pmd_i40e/Makefile | 8 ++- > > > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > > > lib/librte_pmd_pcap/Makefile | 5 +- > > > > > lib/librte_pmd_ring/Makefile | 6 +- > > > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > > > lib/librte_port/Makefile | 8 +-- > > > > > lib/librte_power/Makefile | 4 +- > > > > > lib/librte_ring/Makefile | 2 +- > > > > > lib/librte_sched/Makefile | 7 +- > > > > > lib/librte_table/Makefile | 8 +-- > > > > > lib/librte_timer/Makefile | 6 +- > > > > > lib/librte_vhost/Makefile | 9 +-- > > > > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > > > > mk/rte.app.mk | 53 ++++----------- > > > > > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > > > > > mk/rte.lib.mk | 49 +++----------- > > > > > mk/rte.sdkbuild.mk | 3 - > > > > > mk/rte.sharelib.mk | 101 ---------------------------- > > > > > mk/rte.vars.mk | 9 --- > > > > > 48 files changed, 276 insertions(+), 282 deletions(-) create > > > > > mode > > > > > 100644 lib/librte_core/Makefile create mode 100644 > > > > > mk/rte.corelib.mk delete mode 100644 mk/rte.sharelib.mk > > > > > > > > > > -- > > > > > 1.9.3 > > > > > > > > > > > > > > Something occured to me thinking about this patch set. I noticed > > > > recently that different rules are used to build the shared combined > > > > lib from the individual shared objects. The implication here is > > > > that linker options specified in individual make files (like the > > > > LIBABIVER and EXPORT_MAP options in my ABI versioning script) get > > > > ignored, which is bad. Any other file specific linker options (like > > > > <file>_LDFLAGS specified in individual library makefiles are getting > > dropped for the combined lib. > > > > > > > > It seems like it would be better if the combined libs were > > > > manufactured as linker scripts themselves (textfiles that used > > > > linker directives to include individual libraries under the covers (see > > /lib64/libc.so for an example). > > > > > > > > The disadvantage of such an approach are fairly minimal. With such > > > > a combined library, you still need to install individual libraries, > > > > but for applications that wish to link and run against a single dpdk > > > > library will still work just as they currently do, you can link to just a single > > library. > > > > > > > > The advantage is clear however. By following a linker script > > > > aproach, objects build as separate libraries are built exactly the > > > > same way, using the same rules with the same options. It reduces > > > > the dpdk build environment size and complexity, and reduces the > > > > opportunity for bugs to creep in from forgetting to add build > > > > options to multiple locations. It also provides a more granular > > > > approach for grouping files. Creating a dpdk core library becomes a > > > > matter of creating a one line linker script named libdpdk_core.so, rather > > than re- arraning sections of the build system. > > > > > > > > Thoughts? > > > > Neil > > > > > > > Hi Neil, > > > > > > I think that is a very interesting approach. > > > I have tried to do something similar in this patch by removing > > > rte.sharelib.mk and just having rte.lib.mk to do the linking, leaving > > > as you suggest a single file to modify anything related to building libs. > > > > > > I do think however that your proposal is an improvement over the current > > patch. > > > > > > So basically we want: > > > - get rid of rte.corelib.mk > > > - generate librte_core.so linker script grouping core libs > > > - we do not modify DEPDIR variables > > > - when setting LDLIBS to each lib, we do specify -lrte_core, right? > > > > > Exactly, and librte_core.so is really just a text file containing the following line > > : > > INPUT(-lrte_malloc -lrte_mbuf -lrte_eal ....) > > > > Adding in whatever libraries you want librte_core to consist of. Truthfully, > > you could almost get rid of the COMBINE_LIBS option entirely, and just > > create this file statically if you wanted to (not sure thats the best approach, > > but its definately do-able). > > > Hi Neil, > > Actually, the first patch series does get rid of COMBINE_LIBS entirely. > Sorry, I didn't mean to imply your patch wasn't, just re-iterating that the option is not needed using the alternate method we're discussing, but I really wasn't very clear on that. > So as I was looking into this, by using this approach we do not resolve the interdependencies issue of the core libraries. > We would effectively leave all core libraries (or at least EAL) without proper DT_NEEDED entries. > > Thoughts? > You're correct, or at least what you assert is possible, depending on the implementation. Adding DT_NEEDED entries is something of an orthogonal problem (though your current implementation I think handles it well). You could specify linker directives when building each library so that each DSO contains the proper DT_NEEDED entries (using -l<lib> and --no-as-needed). using a linker script approach doesn't preclude you from doing that, though its not strictly speaking necessecary. When you write the linker script, you implicitly specify the link dependencies by the order in whcih you list the inferior libraries in the scripts INPUT line. It doesn't give you the DT_NEEDED entries, but from an application build/run standpoint, it won't matter, because the libraries will be linked/loaded in the order specified. You can still do the --no-as-needed method though if you like for safety on the part of those using libraries independently. Neil > Regards, > Sergio > > > Regards > > Neil > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150130140507.GA2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150130140507.GA2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-01-30 17:38 ` Gonzalez Monroy, Sergio [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F45534-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-01-30 17:38 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > Sent: Friday, January 30, 2015 2:05 PM > To: Gonzalez Monroy, Sergio > Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > On Fri, Jan 30, 2015 at 01:39:28PM +0000, Gonzalez Monroy, Sergio wrote: > > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > > Sent: Thursday, January 29, 2015 7:46 PM > > > To: Gonzalez Monroy, Sergio > > > Cc: dev-VfR2kkLFssw@public.gmane.org > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > On Thu, Jan 29, 2015 at 05:04:20PM +0000, Gonzalez Monroy, Sergio > wrote: > > > > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > > > > Sent: Thursday, January 29, 2015 4:39 PM > > > > > To: Gonzalez Monroy, Sergio > > > > > Cc: dev-VfR2kkLFssw@public.gmane.org > > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy > > > wrote: > > > > > > This patch series improves the DPDK build system mostly for > > > > > > shared libraries (and a few nits for static libraries) with the following > goals: > > > > > > - Create a library containing core DPDK libraries (librte_eal, > > > > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > > > > The idea of core libraries is to group those libraries that are > > > > > > always required (and have interdependencies) for any DPDK > > > application. > > > > > > - Remove config option to build a combined library. > > > > > > - For shared libraries, explicitly link against dependant > > > > > > libraries (adding entries to DT_NEEDED). > > > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > > > > > Sergio Gonzalez Monroy (8): > > > > > > mk: remove combined library and related options > > > > > > core: create new librte_core > > > > > > mk: new corelib makefile > > > > > > lib: update DEPDIRS variable > > > > > > lib: set LDLIBS for each library > > > > > > mk: use LDLIBS when linking shared libraries > > > > > > mk: update LDLIBS for app building > > > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > > > > > config/common_bsdapp | 6 -- > > > > > > config/common_linuxapp | 6 -- > > > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > > > lib/Makefile | 1 - > > > > > > lib/librte_acl/Makefile | 5 +- > > > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > > > lib/librte_cmdline/Makefile | 6 +- > > > > > > lib/librte_core/Makefile | 45 +++++++++++++ > > > > > > lib/librte_distributor/Makefile | 5 +- > > > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > > > > > lib/librte_ether/Makefile | 4 +- > > > > > > lib/librte_hash/Makefile | 4 +- > > > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > > > lib/librte_kni/Makefile | 6 +- > > > > > > lib/librte_kvargs/Makefile | 6 +- > > > > > > lib/librte_lpm/Makefile | 6 +- > > > > > > lib/librte_malloc/Makefile | 2 +- > > > > > > lib/librte_mbuf/Makefile | 2 +- > > > > > > lib/librte_mempool/Makefile | 2 +- > > > > > > lib/librte_meter/Makefile | 4 +- > > > > > > lib/librte_pipeline/Makefile | 3 + > > > > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > > > > lib/librte_pmd_bond/Makefile | 7 +- > > > > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > > > > lib/librte_pmd_enic/Makefile | 8 ++- > > > > > > lib/librte_pmd_i40e/Makefile | 8 ++- > > > > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > > > > lib/librte_pmd_pcap/Makefile | 5 +- > > > > > > lib/librte_pmd_ring/Makefile | 6 +- > > > > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > > > > lib/librte_port/Makefile | 8 +-- > > > > > > lib/librte_power/Makefile | 4 +- > > > > > > lib/librte_ring/Makefile | 2 +- > > > > > > lib/librte_sched/Makefile | 7 +- > > > > > > lib/librte_table/Makefile | 8 +-- > > > > > > lib/librte_timer/Makefile | 6 +- > > > > > > lib/librte_vhost/Makefile | 9 +-- > > > > > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > > > > > mk/rte.app.mk | 53 ++++----------- > > > > > > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > > > > > > mk/rte.lib.mk | 49 +++----------- > > > > > > mk/rte.sdkbuild.mk | 3 - > > > > > > mk/rte.sharelib.mk | 101 ---------------------------- > > > > > > mk/rte.vars.mk | 9 --- > > > > > > 48 files changed, 276 insertions(+), 282 deletions(-) create > > > > > > mode > > > > > > 100644 lib/librte_core/Makefile create mode 100644 > > > > > > mk/rte.corelib.mk delete mode 100644 mk/rte.sharelib.mk > > > > > > > > > > > > -- > > > > > > 1.9.3 > > > > > > > > > > > > > > > > > Something occured to me thinking about this patch set. I > > > > > noticed recently that different rules are used to build the > > > > > shared combined lib from the individual shared objects. The > > > > > implication here is that linker options specified in individual > > > > > make files (like the LIBABIVER and EXPORT_MAP options in my ABI > > > > > versioning script) get ignored, which is bad. Any other file > > > > > specific linker options (like <file>_LDFLAGS specified in > > > > > individual library makefiles are getting > > > dropped for the combined lib. > > > > > > > > > > It seems like it would be better if the combined libs were > > > > > manufactured as linker scripts themselves (textfiles that used > > > > > linker directives to include individual libraries under the > > > > > covers (see > > > /lib64/libc.so for an example). > > > > > > > > > > The disadvantage of such an approach are fairly minimal. With > > > > > such a combined library, you still need to install individual > > > > > libraries, but for applications that wish to link and run > > > > > against a single dpdk library will still work just as they > > > > > currently do, you can link to just a single > > > library. > > > > > > > > > > The advantage is clear however. By following a linker script > > > > > aproach, objects build as separate libraries are built exactly > > > > > the same way, using the same rules with the same options. It > > > > > reduces the dpdk build environment size and complexity, and > > > > > reduces the opportunity for bugs to creep in from forgetting to > > > > > add build options to multiple locations. It also provides a > > > > > more granular approach for grouping files. Creating a dpdk core > > > > > library becomes a matter of creating a one line linker script > > > > > named libdpdk_core.so, rather > > > than re- arraning sections of the build system. > > > > > > > > > > Thoughts? > > > > > Neil > > > > > > > > > Hi Neil, > > > > > > > > I think that is a very interesting approach. > > > > I have tried to do something similar in this patch by removing > > > > rte.sharelib.mk and just having rte.lib.mk to do the linking, > > > > leaving as you suggest a single file to modify anything related to building > libs. > > > > > > > > I do think however that your proposal is an improvement over the > > > > current > > > patch. > > > > > > > > So basically we want: > > > > - get rid of rte.corelib.mk > > > > - generate librte_core.so linker script grouping core libs > > > > - we do not modify DEPDIR variables > > > > - when setting LDLIBS to each lib, we do specify -lrte_core, right? > > > > > > > Exactly, and librte_core.so is really just a text file containing > > > the following line > > > : > > > INPUT(-lrte_malloc -lrte_mbuf -lrte_eal ....) > > > > > > Adding in whatever libraries you want librte_core to consist of. > > > Truthfully, you could almost get rid of the COMBINE_LIBS option > > > entirely, and just create this file statically if you wanted to (not > > > sure thats the best approach, but its definately do-able). > > > > > Hi Neil, > > > > Actually, the first patch series does get rid of COMBINE_LIBS entirely. > > > Sorry, I didn't mean to imply your patch wasn't, just re-iterating that the > option is not needed using the alternate method we're discussing, but I really > wasn't very clear on that. > > > So as I was looking into this, by using this approach we do not resolve the > interdependencies issue of the core libraries. > > We would effectively leave all core libraries (or at least EAL) without proper > DT_NEEDED entries. > > > > Thoughts? > > > You're correct, or at least what you assert is possible, depending on the > implementation. Adding DT_NEEDED entries is something of an orthogonal > problem (though your current implementation I think handles it well). You > could specify linker directives when building each library so that each DSO > contains the proper DT_NEEDED entries (using -l<lib> and --no-as-needed). > using a linker script approach doesn't preclude you from doing that, though > its not strictly speaking necessecary. When you write the linker script, you > implicitly specify the link dependencies by the order in whcih you list the > inferior libraries in the scripts INPUT line. It doesn't give you the DT_NEEDED > entries, but from an application build/run standpoint, it won't matter, > because the libraries will be linked/loaded in the order specified. You can still > do the --no-as-needed method though if you like for safety on the part of > those using libraries independently. So would it be reasonable to add DT_NEEDED entries to all DPDK libraries but EAL? If I understood what you were saying right, we could enforce the 'dependency' in the linker script with something like this: $ cat librte_eal.so INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such linker script for librte_eal.so instead of the soft link once versioning is in place. Things that would be missing versus the proposed patch: - As I have mention in previous post, ldd info for EAL library would not reflect its dependency to other DPDK libs. - I was enforcing resolving all references when building the libraries (-z defs), so we either remove it altogether or skip eal. - All apps would show DT_NEEDED entries for a set of DPDK libraries that in most cases are required (eal, mempool, malloc, mbuf, ring VS dpdk_core) I think that the linker script approach is reasonable if we prefer to go that way instead of creating a core library. Regards, Sergio > Neil > > > Regards, > > Sergio > > > > > Regards > > > Neil > > > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <91383E96CE459D47BCE92EFBF5CE73B004F45534-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F45534-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-01-30 18:12 ` Neil Horman [not found] ` <20150130181249.GC2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-01-30 18:12 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > Sent: Friday, January 30, 2015 2:05 PM > > To: Gonzalez Monroy, Sergio > > Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Fri, Jan 30, 2015 at 01:39:28PM +0000, Gonzalez Monroy, Sergio wrote: > > > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > > > Sent: Thursday, January 29, 2015 7:46 PM > > > > To: Gonzalez Monroy, Sergio > > > > Cc: dev-VfR2kkLFssw@public.gmane.org > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > On Thu, Jan 29, 2015 at 05:04:20PM +0000, Gonzalez Monroy, Sergio > > wrote: > > > > > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > > > > > Sent: Thursday, January 29, 2015 4:39 PM > > > > > > To: Gonzalez Monroy, Sergio > > > > > > Cc: dev-VfR2kkLFssw@public.gmane.org > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy > > > > wrote: > > > > > > > This patch series improves the DPDK build system mostly for > > > > > > > shared libraries (and a few nits for static libraries) with the following > > goals: > > > > > > > - Create a library containing core DPDK libraries (librte_eal, > > > > > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > > > > > The idea of core libraries is to group those libraries that are > > > > > > > always required (and have interdependencies) for any DPDK > > > > application. > > > > > > > - Remove config option to build a combined library. > > > > > > > - For shared libraries, explicitly link against dependant > > > > > > > libraries (adding entries to DT_NEEDED). > > > > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > > > > > > > Sergio Gonzalez Monroy (8): > > > > > > > mk: remove combined library and related options > > > > > > > core: create new librte_core > > > > > > > mk: new corelib makefile > > > > > > > lib: update DEPDIRS variable > > > > > > > lib: set LDLIBS for each library > > > > > > > mk: use LDLIBS when linking shared libraries > > > > > > > mk: update LDLIBS for app building > > > > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > > > > > > > config/common_bsdapp | 6 -- > > > > > > > config/common_linuxapp | 6 -- > > > > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > > > > lib/Makefile | 1 - > > > > > > > lib/librte_acl/Makefile | 5 +- > > > > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > > > > lib/librte_cmdline/Makefile | 6 +- > > > > > > > lib/librte_core/Makefile | 45 +++++++++++++ > > > > > > > lib/librte_distributor/Makefile | 5 +- > > > > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > > > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > > > > > > lib/librte_ether/Makefile | 4 +- > > > > > > > lib/librte_hash/Makefile | 4 +- > > > > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > > > > lib/librte_kni/Makefile | 6 +- > > > > > > > lib/librte_kvargs/Makefile | 6 +- > > > > > > > lib/librte_lpm/Makefile | 6 +- > > > > > > > lib/librte_malloc/Makefile | 2 +- > > > > > > > lib/librte_mbuf/Makefile | 2 +- > > > > > > > lib/librte_mempool/Makefile | 2 +- > > > > > > > lib/librte_meter/Makefile | 4 +- > > > > > > > lib/librte_pipeline/Makefile | 3 + > > > > > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > > > > > lib/librte_pmd_bond/Makefile | 7 +- > > > > > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > > > > > lib/librte_pmd_enic/Makefile | 8 ++- > > > > > > > lib/librte_pmd_i40e/Makefile | 8 ++- > > > > > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > > > > > lib/librte_pmd_pcap/Makefile | 5 +- > > > > > > > lib/librte_pmd_ring/Makefile | 6 +- > > > > > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > > > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > > > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > > > > > lib/librte_port/Makefile | 8 +-- > > > > > > > lib/librte_power/Makefile | 4 +- > > > > > > > lib/librte_ring/Makefile | 2 +- > > > > > > > lib/librte_sched/Makefile | 7 +- > > > > > > > lib/librte_table/Makefile | 8 +-- > > > > > > > lib/librte_timer/Makefile | 6 +- > > > > > > > lib/librte_vhost/Makefile | 9 +-- > > > > > > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > > > > > > mk/rte.app.mk | 53 ++++----------- > > > > > > > mk/rte.corelib.mk | 84 +++++++++++++++++++++++ > > > > > > > mk/rte.lib.mk | 49 +++----------- > > > > > > > mk/rte.sdkbuild.mk | 3 - > > > > > > > mk/rte.sharelib.mk | 101 ---------------------------- > > > > > > > mk/rte.vars.mk | 9 --- > > > > > > > 48 files changed, 276 insertions(+), 282 deletions(-) create > > > > > > > mode > > > > > > > 100644 lib/librte_core/Makefile create mode 100644 > > > > > > > mk/rte.corelib.mk delete mode 100644 mk/rte.sharelib.mk > > > > > > > > > > > > > > -- > > > > > > > 1.9.3 > > > > > > > > > > > > > > > > > > > > Something occured to me thinking about this patch set. I > > > > > > noticed recently that different rules are used to build the > > > > > > shared combined lib from the individual shared objects. The > > > > > > implication here is that linker options specified in individual > > > > > > make files (like the LIBABIVER and EXPORT_MAP options in my ABI > > > > > > versioning script) get ignored, which is bad. Any other file > > > > > > specific linker options (like <file>_LDFLAGS specified in > > > > > > individual library makefiles are getting > > > > dropped for the combined lib. > > > > > > > > > > > > It seems like it would be better if the combined libs were > > > > > > manufactured as linker scripts themselves (textfiles that used > > > > > > linker directives to include individual libraries under the > > > > > > covers (see > > > > /lib64/libc.so for an example). > > > > > > > > > > > > The disadvantage of such an approach are fairly minimal. With > > > > > > such a combined library, you still need to install individual > > > > > > libraries, but for applications that wish to link and run > > > > > > against a single dpdk library will still work just as they > > > > > > currently do, you can link to just a single > > > > library. > > > > > > > > > > > > The advantage is clear however. By following a linker script > > > > > > aproach, objects build as separate libraries are built exactly > > > > > > the same way, using the same rules with the same options. It > > > > > > reduces the dpdk build environment size and complexity, and > > > > > > reduces the opportunity for bugs to creep in from forgetting to > > > > > > add build options to multiple locations. It also provides a > > > > > > more granular approach for grouping files. Creating a dpdk core > > > > > > library becomes a matter of creating a one line linker script > > > > > > named libdpdk_core.so, rather > > > > than re- arraning sections of the build system. > > > > > > > > > > > > Thoughts? > > > > > > Neil > > > > > > > > > > > Hi Neil, > > > > > > > > > > I think that is a very interesting approach. > > > > > I have tried to do something similar in this patch by removing > > > > > rte.sharelib.mk and just having rte.lib.mk to do the linking, > > > > > leaving as you suggest a single file to modify anything related to building > > libs. > > > > > > > > > > I do think however that your proposal is an improvement over the > > > > > current > > > > patch. > > > > > > > > > > So basically we want: > > > > > - get rid of rte.corelib.mk > > > > > - generate librte_core.so linker script grouping core libs > > > > > - we do not modify DEPDIR variables > > > > > - when setting LDLIBS to each lib, we do specify -lrte_core, right? > > > > > > > > > Exactly, and librte_core.so is really just a text file containing > > > > the following line > > > > : > > > > INPUT(-lrte_malloc -lrte_mbuf -lrte_eal ....) > > > > > > > > Adding in whatever libraries you want librte_core to consist of. > > > > Truthfully, you could almost get rid of the COMBINE_LIBS option > > > > entirely, and just create this file statically if you wanted to (not > > > > sure thats the best approach, but its definately do-able). > > > > > > > Hi Neil, > > > > > > Actually, the first patch series does get rid of COMBINE_LIBS entirely. > > > > > Sorry, I didn't mean to imply your patch wasn't, just re-iterating that the > > option is not needed using the alternate method we're discussing, but I really > > wasn't very clear on that. > > > > > So as I was looking into this, by using this approach we do not resolve the > > interdependencies issue of the core libraries. > > > We would effectively leave all core libraries (or at least EAL) without proper > > DT_NEEDED entries. > > > > > > Thoughts? > > > > > You're correct, or at least what you assert is possible, depending on the > > implementation. Adding DT_NEEDED entries is something of an orthogonal > > problem (though your current implementation I think handles it well). You > > could specify linker directives when building each library so that each DSO > > contains the proper DT_NEEDED entries (using -l<lib> and --no-as-needed). > > using a linker script approach doesn't preclude you from doing that, though > > its not strictly speaking necessecary. When you write the linker script, you > > implicitly specify the link dependencies by the order in whcih you list the > > inferior libraries in the scripts INPUT line. It doesn't give you the DT_NEEDED > > entries, but from an application build/run standpoint, it won't matter, > > because the libraries will be linked/loaded in the order specified. You can still > > do the --no-as-needed method though if you like for safety on the part of > > those using libraries independently. > > So would it be reasonable to add DT_NEEDED entries to all DPDK libraries but EAL? > If I understood what you were saying right, we could enforce the 'dependency' in the > linker script with something like this: > $ cat librte_eal.so > INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) > We could have such linker script for librte_eal.so instead of the soft link once > versioning is in place. > Correct. > Things that would be missing versus the proposed patch: > - As I have mention in previous post, ldd info for EAL library would not reflect > its dependency to other DPDK libs. librte_eal.so would no show those dependencies, as far as I know (though I haven't explicitly checked). The subordunate libraries included in the input line, may or may not show dependencies among themselves, depending on your build setup (and the use of --no-as-needed and -l when linking the individual .so libraries. > - I was enforcing resolving all references when building the libraries (-z defs), so > we either remove it altogether or skip eal. I think thats correct, yes. > - All apps would show DT_NEEDED entries for a set of DPDK libraries that > in most cases are required (eal, mempool, malloc, mbuf, ring VS dpdk_core) > I think apps linked to libdpdk_core would have DT_NEEDED entries for libdpdk_core, not the subordonate libraries (though check me on that to be sure). > I think that the linker script approach is reasonable if we prefer to go that way > instead of creating a core library. > I think it would make sense from a build environment point of view, in that it allows library specific flags to be incorporated properly. I think the only downside is that the individual libraries still need to be carried around (though they can be ignored from an application build/run standpoint). You're question should probably be asked of people using COMBINED_LIBS currently to make sure that meets their needs, though I think it will. Neil > Regards, > Sergio > > > Neil > > > > > Regards, > > > Sergio > > > > > > > Regards > > > > Neil > > > > > > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150130181249.GC2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150130181249.GC2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-02-11 11:11 ` Gonzalez Monroy, Sergio [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F4AB9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-11 11:11 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > Sent: Friday, January 30, 2015 6:13 PM > To: Gonzalez Monroy, Sergio > Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote: [snip] > > > > So would it be reasonable to add DT_NEEDED entries to all DPDK libraries > but EAL? > > If I understood what you were saying right, we could enforce the > > 'dependency' in the linker script with something like this: > > $ cat librte_eal.so > > INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > > linker script for librte_eal.so instead of the soft link once > > versioning is in place. > > > Correct. > > > Things that would be missing versus the proposed patch: > > - As I have mention in previous post, ldd info for EAL library would not > reflect > > its dependency to other DPDK libs. > librte_eal.so would no show those dependencies, as far as I know (though I > haven't explicitly checked). The subordunate libraries included in the input > line, may or may not show dependencies among themselves, depending on > your build setup (and the use of --no-as-needed and -l when linking the > individual .so libraries. > > > - I was enforcing resolving all references when building the libraries (-z > defs), so > > we either remove it altogether or skip eal. > I think thats correct, yes. > > > - All apps would show DT_NEEDED entries for a set of DPDK libraries that > > in most cases are required (eal, mempool, malloc, mbuf, ring VS > > dpdk_core) > > > I think apps linked to libdpdk_core would have DT_NEEDED entries for > libdpdk_core, not the subordonate libraries (though check me on that to be > sure). > Just checked on this and they do link against the subordinate libraries, although It does not really matter as we are dropping the 'core' library approach anyway. > > I think that the linker script approach is reasonable if we prefer to > > go that way instead of creating a core library. > > > I think it would make sense from a build environment point of view, in that it > allows library specific flags to be incorporated properly. I think the only > downside is that the individual libraries still need to be carried around > (though they can be ignored from an application build/run standpoint). > You're question should probably be asked of people using COMBINED_LIBS > currently to make sure that meets their needs, though I think it will. > > Neil > So I just realized that I was not having into account a possible scenario, where we have an app built with static dpdk libs then loading a dso with -d option. In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. So to enable such scenario we would need to build PMDs without DT_NEEDED entries. Thoughts? Regards, Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <91383E96CE459D47BCE92EFBF5CE73B004F4AB9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F4AB9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-02-12 5:41 ` Neil Horman [not found] ` <20150212054105.GC5504-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> 2015-02-12 9:22 ` Panu Matilainen 1 sibling, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-12 5:41 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Wed, Feb 11, 2015 at 11:11:13AM +0000, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > Sent: Friday, January 30, 2015 6:13 PM > > To: Gonzalez Monroy, Sergio > > Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote: > > [snip] > > > > > > > So would it be reasonable to add DT_NEEDED entries to all DPDK libraries > > but EAL? > > > If I understood what you were saying right, we could enforce the > > > 'dependency' in the linker script with something like this: > > > $ cat librte_eal.so > > > INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > > > linker script for librte_eal.so instead of the soft link once > > > versioning is in place. > > > > > Correct. > > > > > Things that would be missing versus the proposed patch: > > > - As I have mention in previous post, ldd info for EAL library would not > > reflect > > > its dependency to other DPDK libs. > > librte_eal.so would no show those dependencies, as far as I know (though I > > haven't explicitly checked). The subordunate libraries included in the input > > line, may or may not show dependencies among themselves, depending on > > your build setup (and the use of --no-as-needed and -l when linking the > > individual .so libraries. > > > > > - I was enforcing resolving all references when building the libraries (-z > > defs), so > > > we either remove it altogether or skip eal. > > I think thats correct, yes. > > > > > - All apps would show DT_NEEDED entries for a set of DPDK libraries that > > > in most cases are required (eal, mempool, malloc, mbuf, ring VS > > > dpdk_core) > > > > > I think apps linked to libdpdk_core would have DT_NEEDED entries for > > libdpdk_core, not the subordonate libraries (though check me on that to be > > sure). > > > Just checked on this and they do link against the subordinate libraries, although > It does not really matter as we are dropping the 'core' library approach anyway. > ok, understood. > > > I think that the linker script approach is reasonable if we prefer to > > > go that way instead of creating a core library. > > > > > I think it would make sense from a build environment point of view, in that it > > allows library specific flags to be incorporated properly. I think the only > > downside is that the individual libraries still need to be carried around > > (though they can be ignored from an application build/run standpoint). > > You're question should probably be asked of people using COMBINED_LIBS > > currently to make sure that meets their needs, though I think it will. > > > > Neil > > > So I just realized that I was not having into account a possible scenario, where > we have an app built with static dpdk libs then loading a dso with -d option. > This is very true, but I was under the impression that the only things that were dlopen-able were PMD's, which would not be part of the core library. Was I mistaken? > In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. > So to enable such scenario we would need to build PMDs without DT_NEEDED > entries. > > Thoughts? > As I mentioned above I thought the only thing that would typically be referenced via dlopen would be libraries that were not part of the unified core library. if thats not the case, then yes, we need a little more thought here Neil > Regards, > Sergio > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150212054105.GC5504-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150212054105.GC5504-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> @ 2015-02-12 9:17 ` Gonzalez Monroy, Sergio [not found] ` <54DC6FB3.8020608-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-12 9:17 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 12/02/2015 05:41, Neil Horman wrote: > On Wed, Feb 11, 2015 at 11:11:13AM +0000, Gonzalez Monroy, Sergio wrote: >>> From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] >>> Sent: Friday, January 30, 2015 6:13 PM >>> To: Gonzalez Monroy, Sergio >>> Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org >>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >>> >>> On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote: >> [snip] >> >>>> So would it be reasonable to add DT_NEEDED entries to all DPDK libraries >>> but EAL? >>>> If I understood what you were saying right, we could enforce the >>>> 'dependency' in the linker script with something like this: >>>> $ cat librte_eal.so >>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>>> linker script for librte_eal.so instead of the soft link once >>>> versioning is in place. >>>> >>> Correct. >>> >>>> Things that would be missing versus the proposed patch: >>>> - As I have mention in previous post, ldd info for EAL library would not >>> reflect >>>> its dependency to other DPDK libs. >>> librte_eal.so would no show those dependencies, as far as I know (though I >>> haven't explicitly checked). The subordunate libraries included in the input >>> line, may or may not show dependencies among themselves, depending on >>> your build setup (and the use of --no-as-needed and -l when linking the >>> individual .so libraries. >>> >>>> - I was enforcing resolving all references when building the libraries (-z >>> defs), so >>>> we either remove it altogether or skip eal. >>> I think thats correct, yes. >>> >>>> - All apps would show DT_NEEDED entries for a set of DPDK libraries that >>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>>> dpdk_core) >>>> >>> I think apps linked to libdpdk_core would have DT_NEEDED entries for >>> libdpdk_core, not the subordonate libraries (though check me on that to be >>> sure). >>> >> Just checked on this and they do link against the subordinate libraries, although >> It does not really matter as we are dropping the 'core' library approach anyway. >> > ok, understood. > >>>> I think that the linker script approach is reasonable if we prefer to >>>> go that way instead of creating a core library. >>>> >>> I think it would make sense from a build environment point of view, in that it >>> allows library specific flags to be incorporated properly. I think the only >>> downside is that the individual libraries still need to be carried around >>> (though they can be ignored from an application build/run standpoint). >>> You're question should probably be asked of people using COMBINED_LIBS >>> currently to make sure that meets their needs, though I think it will. >>> >>> Neil >>> >> So I just realized that I was not having into account a possible scenario, where >> we have an app built with static dpdk libs then loading a dso with -d option. >> > This is very true, but I was under the impression that the only things that were > dlopen-able were PMD's, which would not be part of the core library. Was I > mistaken? As far as I know you are right that only PMDs are being dlopen. The proposed patch though, added DT_NEEDED entries for PMDs too, so they would need to be left empty for them to work in such scenario. Is that reasonable? Regards, Sergio >> In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. >> So to enable such scenario we would need to build PMDs without DT_NEEDED >> entries. >> >> Thoughts? >> > As I mentioned above I thought the only thing that would typically be referenced > via dlopen would be libraries that were not part of the unified core library. > if thats not the case, then yes, we need a little more thought here > Neil > >> Regards, >> Sergio >> ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54DC6FB3.8020608-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54DC6FB3.8020608-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-02-12 12:16 ` Neil Horman 0 siblings, 0 replies; 63+ messages in thread From: Neil Horman @ 2015-02-12 12:16 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Thu, Feb 12, 2015 at 09:17:39AM +0000, Gonzalez Monroy, Sergio wrote: > On 12/02/2015 05:41, Neil Horman wrote: > >On Wed, Feb 11, 2015 at 11:11:13AM +0000, Gonzalez Monroy, Sergio wrote: > >>>From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > >>>Sent: Friday, January 30, 2015 6:13 PM > >>>To: Gonzalez Monroy, Sergio > >>>Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > >>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>> > >>>On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote: > >>[snip] > >> > >>>>So would it be reasonable to add DT_NEEDED entries to all DPDK libraries > >>>but EAL? > >>>>If I understood what you were saying right, we could enforce the > >>>>'dependency' in the linker script with something like this: > >>>>$ cat librte_eal.so > >>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>linker script for librte_eal.so instead of the soft link once > >>>>versioning is in place. > >>>> > >>>Correct. > >>> > >>>>Things that would be missing versus the proposed patch: > >>>> - As I have mention in previous post, ldd info for EAL library would not > >>>reflect > >>>> its dependency to other DPDK libs. > >>>librte_eal.so would no show those dependencies, as far as I know (though I > >>>haven't explicitly checked). The subordunate libraries included in the input > >>>line, may or may not show dependencies among themselves, depending on > >>>your build setup (and the use of --no-as-needed and -l when linking the > >>>individual .so libraries. > >>> > >>>> - I was enforcing resolving all references when building the libraries (-z > >>>defs), so > >>>> we either remove it altogether or skip eal. > >>>I think thats correct, yes. > >>> > >>>> - All apps would show DT_NEEDED entries for a set of DPDK libraries that > >>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>dpdk_core) > >>>> > >>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>libdpdk_core, not the subordonate libraries (though check me on that to be > >>>sure). > >>> > >>Just checked on this and they do link against the subordinate libraries, although > >>It does not really matter as we are dropping the 'core' library approach anyway. > >> > >ok, understood. > > > >>>>I think that the linker script approach is reasonable if we prefer to > >>>>go that way instead of creating a core library. > >>>> > >>>I think it would make sense from a build environment point of view, in that it > >>>allows library specific flags to be incorporated properly. I think the only > >>>downside is that the individual libraries still need to be carried around > >>>(though they can be ignored from an application build/run standpoint). > >>>You're question should probably be asked of people using COMBINED_LIBS > >>>currently to make sure that meets their needs, though I think it will. > >>> > >>>Neil > >>> > >>So I just realized that I was not having into account a possible scenario, where > >>we have an app built with static dpdk libs then loading a dso with -d option. > >> > >This is very true, but I was under the impression that the only things that were > >dlopen-able were PMD's, which would not be part of the core library. Was I > >mistaken? > As far as I know you are right that only PMDs are being dlopen. > The proposed patch though, added DT_NEEDED entries for PMDs too, so they > would need to be > left empty for them to work in such scenario. > > Is that reasonable? > Ah, I see now. What you're saying is that, in our proposed scenario, a PMD that requires, say librte_ether, will have a DT_NEEDED entry explicitly for that library, as opposed to libdpdk_core, is that correct? If it is, I think thats ok. We will still need to have the librte_ether library around, because the libdpdk_core DSO will reference it on its INPUT line, and in fact it should already be loaded because of that, rendering the DT_NEEDED entry moot. That is to say, and requirements from a PMD codified in a DT_NEEDED entry should already be satisfied by the application if it properly linked against libdpdk_core. That said, it should also be safe to remove the DT_NEEDED entry from the PMD for the same reason (the fact that any dependent libraries should already be loaded makes it non-useful). I would personally just leave them in place, as they are harmless, and doing so is really just more work, but if you want to remove the DT_NEEDED's from the PMD's it won't hurt anything Or is there another facet to this that I'm missing? Best Neil > Regards, > Sergio > >>In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. > >>So to enable such scenario we would need to build PMDs without DT_NEEDED > >>entries. > >> > >>Thoughts? > >> > >As I mentioned above I thought the only thing that would typically be referenced > >via dlopen would be libraries that were not part of the unified core library. > >if thats not the case, then yes, we need a little more thought here > >Neil > > > >>Regards, > >>Sergio > >> > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/8] Improve build process [not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F4AB9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2015-02-12 5:41 ` Neil Horman @ 2015-02-12 9:22 ` Panu Matilainen [not found] ` <54DC70F3.4020902-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 63+ messages in thread From: Panu Matilainen @ 2015-02-12 9:22 UTC (permalink / raw) To: Gonzalez Monroy, Sergio, Neil Horman; +Cc: dev-VfR2kkLFssw On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: >> From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] >> Sent: Friday, January 30, 2015 6:13 PM >> To: Gonzalez Monroy, Sergio >> Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org >> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >> >> On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote: > > [snip] > >>> >>> So would it be reasonable to add DT_NEEDED entries to all DPDK libraries >> but EAL? >>> If I understood what you were saying right, we could enforce the >>> 'dependency' in the linker script with something like this: >>> $ cat librte_eal.so >>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>> linker script for librte_eal.so instead of the soft link once >>> versioning is in place. >>> >> Correct. >> >>> Things that would be missing versus the proposed patch: >>> - As I have mention in previous post, ldd info for EAL library would not >> reflect >>> its dependency to other DPDK libs. >> librte_eal.so would no show those dependencies, as far as I know (though I >> haven't explicitly checked). The subordunate libraries included in the input >> line, may or may not show dependencies among themselves, depending on >> your build setup (and the use of --no-as-needed and -l when linking the >> individual .so libraries. >> >>> - I was enforcing resolving all references when building the libraries (-z >> defs), so >>> we either remove it altogether or skip eal. >> I think thats correct, yes. >> >>> - All apps would show DT_NEEDED entries for a set of DPDK libraries that >>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>> dpdk_core) >>> >> I think apps linked to libdpdk_core would have DT_NEEDED entries for >> libdpdk_core, not the subordonate libraries (though check me on that to be >> sure). >> > Just checked on this and they do link against the subordinate libraries, although > It does not really matter as we are dropping the 'core' library approach anyway. > >>> I think that the linker script approach is reasonable if we prefer to >>> go that way instead of creating a core library. >>> >> I think it would make sense from a build environment point of view, in that it >> allows library specific flags to be incorporated properly. I think the only >> downside is that the individual libraries still need to be carried around >> (though they can be ignored from an application build/run standpoint). >> You're question should probably be asked of people using COMBINED_LIBS >> currently to make sure that meets their needs, though I think it will. >> >> Neil >> > So I just realized that I was not having into account a possible scenario, where > we have an app built with static dpdk libs then loading a dso with -d option. > > In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. > So to enable such scenario we would need to build PMDs without DT_NEEDED > entries. Hmm, for that to be a problem you'd need to have the PMD built against shared dpdk libs and while the application is built against static dpdk libs. I dont think that's a supportable scenario in any case. Or is there some other scenario that I'm not seeing? - Panu - ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54DC70F3.4020902-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54DC70F3.4020902-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-02-12 10:03 ` Gonzalez Monroy, Sergio [not found] ` <54DC7A87.1090208-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-12 10:03 UTC (permalink / raw) To: Panu Matilainen; +Cc: dev-VfR2kkLFssw On 12/02/2015 09:22, Panu Matilainen wrote: > On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: >>> From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] >>> Sent: Friday, January 30, 2015 6:13 PM >>> To: Gonzalez Monroy, Sergio >>> Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org >>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >>> >>> On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio >>> wrote: >> >> [snip] >> >>>> >>>> So would it be reasonable to add DT_NEEDED entries to all DPDK >>>> libraries >>> but EAL? >>>> If I understood what you were saying right, we could enforce the >>>> 'dependency' in the linker script with something like this: >>>> $ cat librte_eal.so >>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>>> linker script for librte_eal.so instead of the soft link once >>>> versioning is in place. >>>> >>> Correct. >>> >>>> Things that would be missing versus the proposed patch: >>>> - As I have mention in previous post, ldd info for EAL library >>>> would not >>> reflect >>>> its dependency to other DPDK libs. >>> librte_eal.so would no show those dependencies, as far as I know >>> (though I >>> haven't explicitly checked). The subordunate libraries included in >>> the input >>> line, may or may not show dependencies among themselves, depending on >>> your build setup (and the use of --no-as-needed and -l when linking the >>> individual .so libraries. >>> >>>> - I was enforcing resolving all references when building the >>>> libraries (-z >>> defs), so >>>> we either remove it altogether or skip eal. >>> I think thats correct, yes. >>> >>>> - All apps would show DT_NEEDED entries for a set of DPDK >>>> libraries that >>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>>> dpdk_core) >>>> >>> I think apps linked to libdpdk_core would have DT_NEEDED entries for >>> libdpdk_core, not the subordonate libraries (though check me on that >>> to be >>> sure). >>> >> Just checked on this and they do link against the subordinate >> libraries, although >> It does not really matter as we are dropping the 'core' library >> approach anyway. >> >>>> I think that the linker script approach is reasonable if we prefer to >>>> go that way instead of creating a core library. >>>> >>> I think it would make sense from a build environment point of view, >>> in that it >>> allows library specific flags to be incorporated properly. I think >>> the only >>> downside is that the individual libraries still need to be carried >>> around >>> (though they can be ignored from an application build/run standpoint). >>> You're question should probably be asked of people using COMBINED_LIBS >>> currently to make sure that meets their needs, though I think it will. >>> >>> Neil >>> >> So I just realized that I was not having into account a possible >> scenario, where >> we have an app built with static dpdk libs then loading a dso with >> -d option. >> >> In such case, because the pmd would have DT_NEEDED entries, dlopen >> will fail. >> So to enable such scenario we would need to build PMDs without DT_NEEDED >> entries. > > Hmm, for that to be a problem you'd need to have the PMD built against > shared dpdk libs and while the application is built against static > dpdk libs. I dont think that's a supportable scenario in any case. > > Or is there some other scenario that I'm not seeing? > > - Panu - > I agree with you. I suppose it comes down to, do we want to support such scenario? From what I can see, it seems that we do currently support such scenario by building dpdk apps against all static dpdk libs using --whole-archive (all libs and not only PMDs). http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 Am I misunderstanding this? Regards, Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54DC7A87.1090208-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54DC7A87.1090208-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-02-12 12:23 ` Neil Horman [not found] ` <20150212122354.GB8729-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-12 12:23 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Thu, Feb 12, 2015 at 10:03:51AM +0000, Gonzalez Monroy, Sergio wrote: > On 12/02/2015 09:22, Panu Matilainen wrote: > >On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: > >>>From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > >>>Sent: Friday, January 30, 2015 6:13 PM > >>>To: Gonzalez Monroy, Sergio > >>>Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > >>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>> > >>>On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio > >>>wrote: > >> > >>[snip] > >> > >>>> > >>>>So would it be reasonable to add DT_NEEDED entries to all DPDK > >>>>libraries > >>>but EAL? > >>>>If I understood what you were saying right, we could enforce the > >>>>'dependency' in the linker script with something like this: > >>>>$ cat librte_eal.so > >>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>linker script for librte_eal.so instead of the soft link once > >>>>versioning is in place. > >>>> > >>>Correct. > >>> > >>>>Things that would be missing versus the proposed patch: > >>>> - As I have mention in previous post, ldd info for EAL library > >>>>would not > >>>reflect > >>>> its dependency to other DPDK libs. > >>>librte_eal.so would no show those dependencies, as far as I know > >>>(though I > >>>haven't explicitly checked). The subordunate libraries included in > >>>the input > >>>line, may or may not show dependencies among themselves, depending on > >>>your build setup (and the use of --no-as-needed and -l when linking the > >>>individual .so libraries. > >>> > >>>> - I was enforcing resolving all references when building the > >>>>libraries (-z > >>>defs), so > >>>> we either remove it altogether or skip eal. > >>>I think thats correct, yes. > >>> > >>>> - All apps would show DT_NEEDED entries for a set of DPDK > >>>>libraries that > >>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>dpdk_core) > >>>> > >>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>libdpdk_core, not the subordonate libraries (though check me on that > >>>to be > >>>sure). > >>> > >>Just checked on this and they do link against the subordinate libraries, > >>although > >>It does not really matter as we are dropping the 'core' library approach > >>anyway. > >> > >>>>I think that the linker script approach is reasonable if we prefer to > >>>>go that way instead of creating a core library. > >>>> > >>>I think it would make sense from a build environment point of view, in > >>>that it > >>>allows library specific flags to be incorporated properly. I think > >>>the only > >>>downside is that the individual libraries still need to be carried > >>>around > >>>(though they can be ignored from an application build/run standpoint). > >>>You're question should probably be asked of people using COMBINED_LIBS > >>>currently to make sure that meets their needs, though I think it will. > >>> > >>>Neil > >>> > >>So I just realized that I was not having into account a possible > >>scenario, where > >>we have an app built with static dpdk libs then loading a dso with -d > >>option. > >> > >>In such case, because the pmd would have DT_NEEDED entries, dlopen will > >>fail. > >>So to enable such scenario we would need to build PMDs without DT_NEEDED > >>entries. > > > >Hmm, for that to be a problem you'd need to have the PMD built against > >shared dpdk libs and while the application is built against static dpdk > >libs. I dont think that's a supportable scenario in any case. > > > >Or is there some other scenario that I'm not seeing? > > > > - Panu - > > > I agree with you. I suppose it comes down to, do we want to support such > scenario? > > From what I can see, it seems that we do currently support such scenario by > building dpdk apps against all static dpdk libs using --whole-archive (all > libs and not only PMDs). > http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > > Am I misunderstanding this? > Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: 1) Build the DPDK as a static library 2) Link an application against (1) 3) Use the dlopen mechanism to load a PMD built as a DSO Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared objects on which it (the PMD) depends will not exist in the file system. I think the problem is a little bit orthogonal to the libdpdk_core problem you were initially addressing. That is to say, this problem of dlopen-ed PMD's exists regardless of weather you build the DPDK as part of a static or dynamic library. The problems just happen to intersect in their manipulation of the DT_NEEDED entries. Ok, so, given the above, I would say your approach is likely correct, just prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep loading issue for libraries that may not exist in the filesystem, but thats ok, because by all rights, the symbols codified in those needed libraries should already be present in the running application (either made available by the application having statically linked them, or having the linker load them from the proper libraries at run time). Regards Neil > Regards, > Sergio > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150212122354.GB8729-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150212122354.GB8729-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> @ 2015-02-12 14:07 ` Panu Matilainen [not found] ` <54DCB3B6.1010204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Panu Matilainen @ 2015-02-12 14:07 UTC (permalink / raw) To: Neil Horman, Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On 02/12/2015 02:23 PM, Neil Horman wrote: > On Thu, Feb 12, 2015 at 10:03:51AM +0000, Gonzalez Monroy, Sergio wrote: >> On 12/02/2015 09:22, Panu Matilainen wrote: >>> On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: >>>>> From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] >>>>> Sent: Friday, January 30, 2015 6:13 PM >>>>> To: Gonzalez Monroy, Sergio >>>>> Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org >>>>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >>>>> >>>>> On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio >>>>> wrote: >>>> >>>> [snip] >>>> >>>>>> >>>>>> So would it be reasonable to add DT_NEEDED entries to all DPDK >>>>>> libraries >>>>> but EAL? >>>>>> If I understood what you were saying right, we could enforce the >>>>>> 'dependency' in the linker script with something like this: >>>>>> $ cat librte_eal.so >>>>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>>>>> linker script for librte_eal.so instead of the soft link once >>>>>> versioning is in place. >>>>>> >>>>> Correct. >>>>> >>>>>> Things that would be missing versus the proposed patch: >>>>>> - As I have mention in previous post, ldd info for EAL library >>>>>> would not >>>>> reflect >>>>>> its dependency to other DPDK libs. >>>>> librte_eal.so would no show those dependencies, as far as I know >>>>> (though I >>>>> haven't explicitly checked). The subordunate libraries included in >>>>> the input >>>>> line, may or may not show dependencies among themselves, depending on >>>>> your build setup (and the use of --no-as-needed and -l when linking the >>>>> individual .so libraries. >>>>> >>>>>> - I was enforcing resolving all references when building the >>>>>> libraries (-z >>>>> defs), so >>>>>> we either remove it altogether or skip eal. >>>>> I think thats correct, yes. >>>>> >>>>>> - All apps would show DT_NEEDED entries for a set of DPDK >>>>>> libraries that >>>>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>>>>> dpdk_core) >>>>>> >>>>> I think apps linked to libdpdk_core would have DT_NEEDED entries for >>>>> libdpdk_core, not the subordonate libraries (though check me on that >>>>> to be >>>>> sure). >>>>> >>>> Just checked on this and they do link against the subordinate libraries, >>>> although >>>> It does not really matter as we are dropping the 'core' library approach >>>> anyway. >>>> >>>>>> I think that the linker script approach is reasonable if we prefer to >>>>>> go that way instead of creating a core library. >>>>>> >>>>> I think it would make sense from a build environment point of view, in >>>>> that it >>>>> allows library specific flags to be incorporated properly. I think >>>>> the only >>>>> downside is that the individual libraries still need to be carried >>>>> around >>>>> (though they can be ignored from an application build/run standpoint). >>>>> You're question should probably be asked of people using COMBINED_LIBS >>>>> currently to make sure that meets their needs, though I think it will. >>>>> >>>>> Neil >>>>> >>>> So I just realized that I was not having into account a possible >>>> scenario, where >>>> we have an app built with static dpdk libs then loading a dso with -d >>>> option. >>>> >>>> In such case, because the pmd would have DT_NEEDED entries, dlopen will >>>> fail. >>>> So to enable such scenario we would need to build PMDs without DT_NEEDED >>>> entries. >>> >>> Hmm, for that to be a problem you'd need to have the PMD built against >>> shared dpdk libs and while the application is built against static dpdk >>> libs. I dont think that's a supportable scenario in any case. >>> >>> Or is there some other scenario that I'm not seeing? >>> >>> - Panu - >>> >> I agree with you. I suppose it comes down to, do we want to support such >> scenario? >> >> From what I can see, it seems that we do currently support such scenario by >> building dpdk apps against all static dpdk libs using --whole-archive (all >> libs and not only PMDs). >> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >> >> Am I misunderstanding this? >> > Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Use the dlopen mechanism to load a PMD built as a DSO > > Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared > objects on which it (the PMD) depends will not exist in the file system. I think its even more twisty: 1) Build the DPDK as a static library 2) Link an application against (1) 3) Do another build of DPDK as a shared library 4) In app 2), use the dlopen mechanism to load a PMD built as a part of or against 3) Somehow I doubt this would work very well. > > I think the problem is a little bit orthogonal to the libdpdk_core problem you > were initially addressing. That is to say, this problem of dlopen-ed PMD's > exists regardless of weather you build the DPDK as part of a static or dynamic > library. The problems just happen to intersect in their manipulation of the > DT_NEEDED entries. > > Ok, so, given the above, I would say your approach is likely correct, just > prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep > loading issue for libraries that may not exist in the filesystem, but thats ok, > because by all rights, the symbols codified in those needed libraries should > already be present in the running application (either made available by the > application having statically linked them, or having the linker load them from > the proper libraries at run time). My 5c is that I'd much rather see the common case (all static or all shared) be simple and reliable, which in case of DSOs includes no lying (whether by omission or otherwise) about DT_NEEDED, ever. That way the issue is dealt once where it belongs. If somebody wants to go down the rabbit hole of mixed shared + static linkage, let them dig the hole by themselves :) - Panu - > Regards > Neil > >> Regards, >> Sergio >> ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54DCB3B6.1010204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54DCB3B6.1010204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-02-12 15:52 ` Neil Horman [not found] ` <20150212155225.GB4634-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-12 15:52 UTC (permalink / raw) To: Panu Matilainen; +Cc: dev-VfR2kkLFssw On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > On 02/12/2015 02:23 PM, Neil Horman wrote: > >On Thu, Feb 12, 2015 at 10:03:51AM +0000, Gonzalez Monroy, Sergio wrote: > >>On 12/02/2015 09:22, Panu Matilainen wrote: > >>>On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: > >>>>>From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > >>>>>Sent: Friday, January 30, 2015 6:13 PM > >>>>>To: Gonzalez Monroy, Sergio > >>>>>Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org > >>>>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>>>> > >>>>>On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio > >>>>>wrote: > >>>> > >>>>[snip] > >>>> > >>>>>> > >>>>>>So would it be reasonable to add DT_NEEDED entries to all DPDK > >>>>>>libraries > >>>>>but EAL? > >>>>>>If I understood what you were saying right, we could enforce the > >>>>>>'dependency' in the linker script with something like this: > >>>>>>$ cat librte_eal.so > >>>>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>>>linker script for librte_eal.so instead of the soft link once > >>>>>>versioning is in place. > >>>>>> > >>>>>Correct. > >>>>> > >>>>>>Things that would be missing versus the proposed patch: > >>>>>> - As I have mention in previous post, ldd info for EAL library > >>>>>>would not > >>>>>reflect > >>>>>> its dependency to other DPDK libs. > >>>>>librte_eal.so would no show those dependencies, as far as I know > >>>>>(though I > >>>>>haven't explicitly checked). The subordunate libraries included in > >>>>>the input > >>>>>line, may or may not show dependencies among themselves, depending on > >>>>>your build setup (and the use of --no-as-needed and -l when linking the > >>>>>individual .so libraries. > >>>>> > >>>>>> - I was enforcing resolving all references when building the > >>>>>>libraries (-z > >>>>>defs), so > >>>>>> we either remove it altogether or skip eal. > >>>>>I think thats correct, yes. > >>>>> > >>>>>> - All apps would show DT_NEEDED entries for a set of DPDK > >>>>>>libraries that > >>>>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>>>dpdk_core) > >>>>>> > >>>>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>>>libdpdk_core, not the subordonate libraries (though check me on that > >>>>>to be > >>>>>sure). > >>>>> > >>>>Just checked on this and they do link against the subordinate libraries, > >>>>although > >>>>It does not really matter as we are dropping the 'core' library approach > >>>>anyway. > >>>> > >>>>>>I think that the linker script approach is reasonable if we prefer to > >>>>>>go that way instead of creating a core library. > >>>>>> > >>>>>I think it would make sense from a build environment point of view, in > >>>>>that it > >>>>>allows library specific flags to be incorporated properly. I think > >>>>>the only > >>>>>downside is that the individual libraries still need to be carried > >>>>>around > >>>>>(though they can be ignored from an application build/run standpoint). > >>>>>You're question should probably be asked of people using COMBINED_LIBS > >>>>>currently to make sure that meets their needs, though I think it will. > >>>>> > >>>>>Neil > >>>>> > >>>>So I just realized that I was not having into account a possible > >>>>scenario, where > >>>>we have an app built with static dpdk libs then loading a dso with -d > >>>>option. > >>>> > >>>>In such case, because the pmd would have DT_NEEDED entries, dlopen will > >>>>fail. > >>>>So to enable such scenario we would need to build PMDs without DT_NEEDED > >>>>entries. > >>> > >>>Hmm, for that to be a problem you'd need to have the PMD built against > >>>shared dpdk libs and while the application is built against static dpdk > >>>libs. I dont think that's a supportable scenario in any case. > >>> > >>>Or is there some other scenario that I'm not seeing? > >>> > >>> - Panu - > >>> > >>I agree with you. I suppose it comes down to, do we want to support such > >>scenario? > >> > >> From what I can see, it seems that we do currently support such scenario by > >>building dpdk apps against all static dpdk libs using --whole-archive (all > >>libs and not only PMDs). > >>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >> > >>Am I misunderstanding this? > >> > >Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: > > > >1) Build the DPDK as a static library > >2) Link an application against (1) > >3) Use the dlopen mechanism to load a PMD built as a DSO > > > >Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared > >objects on which it (the PMD) depends will not exist in the file system. > > I think its even more twisty: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Do another build of DPDK as a shared library > 4) In app 2), use the dlopen mechanism to load a PMD built as a part of or > against 3) > > Somehow I doubt this would work very well. > Ideally it should, presuming the ABI is preserved between (1) and (3), though I agree, up until recently, that was an assumption that was unreliable. > > > >I think the problem is a little bit orthogonal to the libdpdk_core problem you > >were initially addressing. That is to say, this problem of dlopen-ed PMD's > >exists regardless of weather you build the DPDK as part of a static or dynamic > >library. The problems just happen to intersect in their manipulation of the > >DT_NEEDED entries. > > > >Ok, so, given the above, I would say your approach is likely correct, just > >prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep > >loading issue for libraries that may not exist in the filesystem, but thats ok, > >because by all rights, the symbols codified in those needed libraries should > >already be present in the running application (either made available by the > >application having statically linked them, or having the linker load them from > >the proper libraries at run time). > > My 5c is that I'd much rather see the common case (all static or all shared) > be simple and reliable, which in case of DSOs includes no lying (whether by > omission or otherwise) about DT_NEEDED, ever. That way the issue is dealt > once where it belongs. If somebody wants to go down the rabbit hole of mixed > shared + static linkage, let them dig the hole by themselves :) > This is a fair point. Can DT_NEEDED sections be stripped via tools like objcopy after the build is complete? If so, end users can hack this corner case to work as needed. Neil > - Panu - > > >Regards > >Neil > > > >>Regards, > >>Sergio > >> > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150212155225.GB4634-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150212155225.GB4634-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> @ 2015-02-13 10:14 ` Panu Matilainen [not found] ` <54DDCE68.7090400-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Panu Matilainen @ 2015-02-13 10:14 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 02/12/2015 05:52 PM, Neil Horman wrote: > On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >> On 02/12/2015 02:23 PM, Neil Horman wrote: [...snip...] >>>>>>> >>>>>> So I just realized that I was not having into account a possible >>>>>> scenario, where >>>>>> we have an app built with static dpdk libs then loading a dso with -d >>>>>> option. >>>>>> >>>>>> In such case, because the pmd would have DT_NEEDED entries, dlopen will >>>>>> fail. >>>>>> So to enable such scenario we would need to build PMDs without DT_NEEDED >>>>>> entries. >>>>> >>>>> Hmm, for that to be a problem you'd need to have the PMD built against >>>>> shared dpdk libs and while the application is built against static dpdk >>>>> libs. I dont think that's a supportable scenario in any case. >>>>> >>>>> Or is there some other scenario that I'm not seeing? >>>>> >>>>> - Panu - >>>>> >>>> I agree with you. I suppose it comes down to, do we want to support such >>>> scenario? >>>> >>>> From what I can see, it seems that we do currently support such scenario by >>>> building dpdk apps against all static dpdk libs using --whole-archive (all >>>> libs and not only PMDs). >>>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>>> >>>> Am I misunderstanding this? >>>> >>> Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: >>> >>> 1) Build the DPDK as a static library >>> 2) Link an application against (1) >>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>> >>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared >>> objects on which it (the PMD) depends will not exist in the file system. >> >> I think its even more twisty: >> >> 1) Build the DPDK as a static library >> 2) Link an application against (1) >> 3) Do another build of DPDK as a shared library >> 4) In app 2), use the dlopen mechanism to load a PMD built as a part of or >> against 3) >> >> Somehow I doubt this would work very well. >> > Ideally it should, presuming the ABI is preserved between (1) and (3), though I > agree, up until recently, that was an assumption that was unreliable. Versioning is a big and important step towards reliability but there are more issues to solve. This of course getting pretty far from the original topic, but at least one such issue is that there are some cases where a config value affects what are apparently public structs (rte_mbuf wrt RTE_MBUF_REFCNT for example), which really is a no-go. >>> >>> I think the problem is a little bit orthogonal to the libdpdk_core problem you >>> were initially addressing. That is to say, this problem of dlopen-ed PMD's >>> exists regardless of weather you build the DPDK as part of a static or dynamic >>> library. The problems just happen to intersect in their manipulation of the >>> DT_NEEDED entries. >>> >>> Ok, so, given the above, I would say your approach is likely correct, just >>> prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep >>> loading issue for libraries that may not exist in the filesystem, but thats ok, >>> because by all rights, the symbols codified in those needed libraries should >>> already be present in the running application (either made available by the >>> application having statically linked them, or having the linker load them from >>> the proper libraries at run time). >> >> My 5c is that I'd much rather see the common case (all static or all shared) >> be simple and reliable, which in case of DSOs includes no lying (whether by >> omission or otherwise) about DT_NEEDED, ever. That way the issue is dealt >> once where it belongs. If somebody wants to go down the rabbit hole of mixed >> shared + static linkage, let them dig the hole by themselves :) >> > This is a fair point. Can DT_NEEDED sections be stripped via tools like objcopy > after the build is complete? If so, end users can hack this corner case to work > as needed. Patchelf (http://nixos.org/patchelf.html) appears to support that, but given that source is available it'd be easier to just modify the makefiles if that's really needed. - Panu - ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54DDCE68.7090400-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54DDCE68.7090400-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-02-13 11:08 ` Gonzalez Monroy, Sergio [not found] ` <54DDDB12.3090100-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-13 11:08 UTC (permalink / raw) To: Panu Matilainen; +Cc: dev-VfR2kkLFssw On 13/02/2015 10:14, Panu Matilainen wrote: > On 02/12/2015 05:52 PM, Neil Horman wrote: >> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>> On 02/12/2015 02:23 PM, Neil Horman wrote: > [...snip...] >>>>>>>> >>>>>>> So I just realized that I was not having into account a possible >>>>>>> scenario, where >>>>>>> we have an app built with static dpdk libs then loading a dso >>>>>>> with -d >>>>>>> option. >>>>>>> >>>>>>> In such case, because the pmd would have DT_NEEDED entries, >>>>>>> dlopen will >>>>>>> fail. >>>>>>> So to enable such scenario we would need to build PMDs without >>>>>>> DT_NEEDED >>>>>>> entries. >>>>>> >>>>>> Hmm, for that to be a problem you'd need to have the PMD built >>>>>> against >>>>>> shared dpdk libs and while the application is built against >>>>>> static dpdk >>>>>> libs. I dont think that's a supportable scenario in any case. >>>>>> >>>>>> Or is there some other scenario that I'm not seeing? >>>>>> >>>>>> - Panu - >>>>>> >>>>> I agree with you. I suppose it comes down to, do we want to >>>>> support such >>>>> scenario? >>>>> >>>>> From what I can see, it seems that we do currently support such >>>>> scenario by >>>>> building dpdk apps against all static dpdk libs using >>>>> --whole-archive (all >>>>> libs and not only PMDs). >>>>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>>>> >>>>> >>>>> Am I misunderstanding this? >>>>> >>>> Shoot, you're right, I missed the static build aspect to this. >>>> Yes, if we do the following: >>>> >>>> 1) Build the DPDK as a static library >>>> 2) Link an application against (1) >>>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>>> >>>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >>>> the shared >>>> objects on which it (the PMD) depends will not exist in the file >>>> system. >>> >>> I think its even more twisty: >>> >>> 1) Build the DPDK as a static library >>> 2) Link an application against (1) >>> 3) Do another build of DPDK as a shared library >>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>> of or >>> against 3) >>> >>> Somehow I doubt this would work very well. >>> >> Ideally it should, presuming the ABI is preserved between (1) and >> (3), though I >> agree, up until recently, that was an assumption that was unreliable. > > Versioning is a big and important step towards reliability but there > are more issues to solve. This of course getting pretty far from the > original topic, but at least one such issue is that there are some > cases where a config value affects what are apparently public structs > (rte_mbuf wrt RTE_MBUF_REFCNT for example), which really is a no-go. > Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. I'll look into it. >>>> >>>> I think the problem is a little bit orthogonal to the libdpdk_core >>>> problem you >>>> were initially addressing. That is to say, this problem of >>>> dlopen-ed PMD's >>>> exists regardless of weather you build the DPDK as part of a static >>>> or dynamic >>>> library. The problems just happen to intersect in their >>>> manipulation of the >>>> DT_NEEDED entries. >>>> >>>> Ok, so, given the above, I would say your approach is likely >>>> correct, just >>>> prevent DT_NEEDED entries from getting added to PMD's. Doing so >>>> will sidestep >>>> loading issue for libraries that may not exist in the filesystem, >>>> but thats ok, >>>> because by all rights, the symbols codified in those needed >>>> libraries should >>>> already be present in the running application (either made >>>> available by the >>>> application having statically linked them, or having the linker >>>> load them from >>>> the proper libraries at run time). >>> >>> My 5c is that I'd much rather see the common case (all static or all >>> shared) >>> be simple and reliable, which in case of DSOs includes no lying >>> (whether by >>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>> dealt >>> once where it belongs. If somebody wants to go down the rabbit hole >>> of mixed >>> shared + static linkage, let them dig the hole by themselves :) >>> >> This is a fair point. Can DT_NEEDED sections be stripped via tools >> like objcopy >> after the build is complete? If so, end users can hack this corner >> case to work >> as needed. > > Patchelf (http://nixos.org/patchelf.html) appears to support that, but > given that source is available it'd be easier to just modify the > makefiles if that's really needed. > I think we agree on the issue. So I'll be sending a patch to add DT_NEEDED entries to all libraries and PMDs. The only exception would be librte_eal, which would not have proper NEEDED entries. Do we bother adding a linker script for librte_eal that would include dependent libraries? Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54DDDB12.3090100-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54DDDB12.3090100-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-02-13 12:51 ` Neil Horman [not found] ` <20150213125142.GA11979-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-13 12:51 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: > On 13/02/2015 10:14, Panu Matilainen wrote: > >On 02/12/2015 05:52 PM, Neil Horman wrote: > >>On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >>>On 02/12/2015 02:23 PM, Neil Horman wrote: > >[...snip...] > >>>>>>>> > >>>>>>>So I just realized that I was not having into account a possible > >>>>>>>scenario, where > >>>>>>>we have an app built with static dpdk libs then loading a dso > >>>>>>>with -d > >>>>>>>option. > >>>>>>> > >>>>>>>In such case, because the pmd would have DT_NEEDED entries, > >>>>>>>dlopen will > >>>>>>>fail. > >>>>>>>So to enable such scenario we would need to build PMDs without > >>>>>>>DT_NEEDED > >>>>>>>entries. > >>>>>> > >>>>>>Hmm, for that to be a problem you'd need to have the PMD built > >>>>>>against > >>>>>>shared dpdk libs and while the application is built against > >>>>>>static dpdk > >>>>>>libs. I dont think that's a supportable scenario in any case. > >>>>>> > >>>>>>Or is there some other scenario that I'm not seeing? > >>>>>> > >>>>>> - Panu - > >>>>>> > >>>>>I agree with you. I suppose it comes down to, do we want to > >>>>>support such > >>>>>scenario? > >>>>> > >>>>> From what I can see, it seems that we do currently support such > >>>>>scenario by > >>>>>building dpdk apps against all static dpdk libs using > >>>>>--whole-archive (all > >>>>>libs and not only PMDs). > >>>>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >>>>> > >>>>> > >>>>>Am I misunderstanding this? > >>>>> > >>>>Shoot, you're right, I missed the static build aspect to this. Yes, > >>>>if we do the following: > >>>> > >>>>1) Build the DPDK as a static library > >>>>2) Link an application against (1) > >>>>3) Use the dlopen mechanism to load a PMD built as a DSO > >>>> > >>>>Then the DT_NEEDED entries in the DSO will go unsatisfied, because > >>>>the shared > >>>>objects on which it (the PMD) depends will not exist in the file > >>>>system. > >>> > >>>I think its even more twisty: > >>> > >>>1) Build the DPDK as a static library > >>>2) Link an application against (1) > >>>3) Do another build of DPDK as a shared library > >>>4) In app 2), use the dlopen mechanism to load a PMD built as a part > >>>of or > >>>against 3) > >>> > >>>Somehow I doubt this would work very well. > >>> > >>Ideally it should, presuming the ABI is preserved between (1) and (3), > >>though I > >>agree, up until recently, that was an assumption that was unreliable. > > > >Versioning is a big and important step towards reliability but there are > >more issues to solve. This of course getting pretty far from the original > >topic, but at least one such issue is that there are some cases where a > >config value affects what are apparently public structs (rte_mbuf wrt > >RTE_MBUF_REFCNT for example), which really is a no-go. > > > Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > I'll look into it. > > >>>> > >>>>I think the problem is a little bit orthogonal to the libdpdk_core > >>>>problem you > >>>>were initially addressing. That is to say, this problem of > >>>>dlopen-ed PMD's > >>>>exists regardless of weather you build the DPDK as part of a static > >>>>or dynamic > >>>>library. The problems just happen to intersect in their > >>>>manipulation of the > >>>>DT_NEEDED entries. > >>>> > >>>>Ok, so, given the above, I would say your approach is likely > >>>>correct, just > >>>>prevent DT_NEEDED entries from getting added to PMD's. Doing so will > >>>>sidestep > >>>>loading issue for libraries that may not exist in the filesystem, > >>>>but thats ok, > >>>>because by all rights, the symbols codified in those needed > >>>>libraries should > >>>>already be present in the running application (either made available > >>>>by the > >>>>application having statically linked them, or having the linker load > >>>>them from > >>>>the proper libraries at run time). > >>> > >>>My 5c is that I'd much rather see the common case (all static or all > >>>shared) > >>>be simple and reliable, which in case of DSOs includes no lying > >>>(whether by > >>>omission or otherwise) about DT_NEEDED, ever. That way the issue is > >>>dealt > >>>once where it belongs. If somebody wants to go down the rabbit hole of > >>>mixed > >>>shared + static linkage, let them dig the hole by themselves :) > >>> > >>This is a fair point. Can DT_NEEDED sections be stripped via tools like > >>objcopy > >>after the build is complete? If so, end users can hack this corner case > >>to work > >>as needed. > > > >Patchelf (http://nixos.org/patchelf.html) appears to support that, but > >given that source is available it'd be easier to just modify the makefiles > >if that's really needed. > > > I think we agree on the issue. > > So I'll be sending a patch to add DT_NEEDED entries to all libraries and > PMDs. The only exception would be librte_eal, which would not have proper > NEEDED entries. > Do we bother adding a linker script for librte_eal that would include > dependent libraries? > I say yes to the linker script, but will happily bow to an alternate consensus Neil > Sergio > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150213125142.GA11979-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150213125142.GA11979-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> @ 2015-02-20 14:31 ` Gonzalez Monroy, Sergio [not found] ` <54E74548.7010805-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-20 14:31 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 13/02/2015 12:51, Neil Horman wrote: > On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: >> On 13/02/2015 10:14, Panu Matilainen wrote: >>> On 02/12/2015 05:52 PM, Neil Horman wrote: >>>> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>>>> On 02/12/2015 02:23 PM, Neil Horman wrote: >>> [...snip...] >>>>>>>>> So I just realized that I was not having into account a possible >>>>>>>>> scenario, where >>>>>>>>> we have an app built with static dpdk libs then loading a dso >>>>>>>>> with -d >>>>>>>>> option. >>>>>>>>> >>>>>>>>> In such case, because the pmd would have DT_NEEDED entries, >>>>>>>>> dlopen will >>>>>>>>> fail. >>>>>>>>> So to enable such scenario we would need to build PMDs without >>>>>>>>> DT_NEEDED >>>>>>>>> entries. >>>>>>>> Hmm, for that to be a problem you'd need to have the PMD built >>>>>>>> against >>>>>>>> shared dpdk libs and while the application is built against >>>>>>>> static dpdk >>>>>>>> libs. I dont think that's a supportable scenario in any case. >>>>>>>> >>>>>>>> Or is there some other scenario that I'm not seeing? >>>>>>>> >>>>>>>> - Panu - >>>>>>>> >>>>>>> I agree with you. I suppose it comes down to, do we want to >>>>>>> support such >>>>>>> scenario? >>>>>>> >>>>>>> From what I can see, it seems that we do currently support such >>>>>>> scenario by >>>>>>> building dpdk apps against all static dpdk libs using >>>>>>> --whole-archive (all >>>>>>> libs and not only PMDs). >>>>>>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>>>>>> >>>>>>> >>>>>>> Am I misunderstanding this? >>>>>>> >>>>>> Shoot, you're right, I missed the static build aspect to this. Yes, >>>>>> if we do the following: >>>>>> >>>>>> 1) Build the DPDK as a static library >>>>>> 2) Link an application against (1) >>>>>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>>>>> >>>>>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >>>>>> the shared >>>>>> objects on which it (the PMD) depends will not exist in the file >>>>>> system. >>>>> I think its even more twisty: >>>>> >>>>> 1) Build the DPDK as a static library >>>>> 2) Link an application against (1) >>>>> 3) Do another build of DPDK as a shared library >>>>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>>>> of or >>>>> against 3) >>>>> >>>>> Somehow I doubt this would work very well. >>>>> >>>> Ideally it should, presuming the ABI is preserved between (1) and (3), >>>> though I >>>> agree, up until recently, that was an assumption that was unreliable. >>> Versioning is a big and important step towards reliability but there are >>> more issues to solve. This of course getting pretty far from the original >>> topic, but at least one such issue is that there are some cases where a >>> config value affects what are apparently public structs (rte_mbuf wrt >>> RTE_MBUF_REFCNT for example), which really is a no-go. >>> >> Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. >> I'll look into it. >> >>>>>> I think the problem is a little bit orthogonal to the libdpdk_core >>>>>> problem you >>>>>> were initially addressing. That is to say, this problem of >>>>>> dlopen-ed PMD's >>>>>> exists regardless of weather you build the DPDK as part of a static >>>>>> or dynamic >>>>>> library. The problems just happen to intersect in their >>>>>> manipulation of the >>>>>> DT_NEEDED entries. >>>>>> >>>>>> Ok, so, given the above, I would say your approach is likely >>>>>> correct, just >>>>>> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >>>>>> sidestep >>>>>> loading issue for libraries that may not exist in the filesystem, >>>>>> but thats ok, >>>>>> because by all rights, the symbols codified in those needed >>>>>> libraries should >>>>>> already be present in the running application (either made available >>>>>> by the >>>>>> application having statically linked them, or having the linker load >>>>>> them from >>>>>> the proper libraries at run time). >>>>> My 5c is that I'd much rather see the common case (all static or all >>>>> shared) >>>>> be simple and reliable, which in case of DSOs includes no lying >>>>> (whether by >>>>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>>>> dealt >>>>> once where it belongs. If somebody wants to go down the rabbit hole of >>>>> mixed >>>>> shared + static linkage, let them dig the hole by themselves :) >>>>> >>>> This is a fair point. Can DT_NEEDED sections be stripped via tools like >>>> objcopy >>>> after the build is complete? If so, end users can hack this corner case >>>> to work >>>> as needed. >>> Patchelf (http://nixos.org/patchelf.html) appears to support that, but >>> given that source is available it'd be easier to just modify the makefiles >>> if that's really needed. >>> >> I think we agree on the issue. >> >> So I'll be sending a patch to add DT_NEEDED entries to all libraries and >> PMDs. The only exception would be librte_eal, which would not have proper >> NEEDED entries. >> Do we bother adding a linker script for librte_eal that would include >> dependent libraries? >> > I say yes to the linker script, but will happily bow to an alternate consensus > Neil > So the case we want to solve is the following circular dependencies: eal -> mempool, malloc mempool -> eal , malloc, ring malloc -> eal ring -> eal, malloc We cannot write/create the proposed (below) linker script at least until we have built mempool and malloc. INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) Few ways I have thought about implementing this (not particularly fond of any of them) : - Have the linker script file in the repo (scripts/ ?) in a fixed location and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. - Generate the file on build time from a defined make variable once all libs have finished Thoughts? any other approached is more than welcome! Sergio PS: Thinking again on the core library and the issue of having multiple version.map files, we could have a core_version.map instead instead of multiple files per core library (eal, mempool, etc) ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54E74548.7010805-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54E74548.7010805-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-02-22 23:37 ` Neil Horman [not found] ` <20150222233740.GB31293-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-22 23:37 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Fri, Feb 20, 2015 at 02:31:36PM +0000, Gonzalez Monroy, Sergio wrote: > On 13/02/2015 12:51, Neil Horman wrote: > >On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: > >>On 13/02/2015 10:14, Panu Matilainen wrote: > >>>On 02/12/2015 05:52 PM, Neil Horman wrote: > >>>>On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >>>>>On 02/12/2015 02:23 PM, Neil Horman wrote: > >>>[...snip...] > >>>>>>>>>So I just realized that I was not having into account a possible > >>>>>>>>>scenario, where > >>>>>>>>>we have an app built with static dpdk libs then loading a dso > >>>>>>>>>with -d > >>>>>>>>>option. > >>>>>>>>> > >>>>>>>>>In such case, because the pmd would have DT_NEEDED entries, > >>>>>>>>>dlopen will > >>>>>>>>>fail. > >>>>>>>>>So to enable such scenario we would need to build PMDs without > >>>>>>>>>DT_NEEDED > >>>>>>>>>entries. > >>>>>>>>Hmm, for that to be a problem you'd need to have the PMD built > >>>>>>>>against > >>>>>>>>shared dpdk libs and while the application is built against > >>>>>>>>static dpdk > >>>>>>>>libs. I dont think that's a supportable scenario in any case. > >>>>>>>> > >>>>>>>>Or is there some other scenario that I'm not seeing? > >>>>>>>> > >>>>>>>> - Panu - > >>>>>>>> > >>>>>>>I agree with you. I suppose it comes down to, do we want to > >>>>>>>support such > >>>>>>>scenario? > >>>>>>> > >>>>>>> From what I can see, it seems that we do currently support such > >>>>>>>scenario by > >>>>>>>building dpdk apps against all static dpdk libs using > >>>>>>>--whole-archive (all > >>>>>>>libs and not only PMDs). > >>>>>>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >>>>>>> > >>>>>>> > >>>>>>>Am I misunderstanding this? > >>>>>>> > >>>>>>Shoot, you're right, I missed the static build aspect to this. Yes, > >>>>>>if we do the following: > >>>>>> > >>>>>>1) Build the DPDK as a static library > >>>>>>2) Link an application against (1) > >>>>>>3) Use the dlopen mechanism to load a PMD built as a DSO > >>>>>> > >>>>>>Then the DT_NEEDED entries in the DSO will go unsatisfied, because > >>>>>>the shared > >>>>>>objects on which it (the PMD) depends will not exist in the file > >>>>>>system. > >>>>>I think its even more twisty: > >>>>> > >>>>>1) Build the DPDK as a static library > >>>>>2) Link an application against (1) > >>>>>3) Do another build of DPDK as a shared library > >>>>>4) In app 2), use the dlopen mechanism to load a PMD built as a part > >>>>>of or > >>>>>against 3) > >>>>> > >>>>>Somehow I doubt this would work very well. > >>>>> > >>>>Ideally it should, presuming the ABI is preserved between (1) and (3), > >>>>though I > >>>>agree, up until recently, that was an assumption that was unreliable. > >>>Versioning is a big and important step towards reliability but there are > >>>more issues to solve. This of course getting pretty far from the original > >>>topic, but at least one such issue is that there are some cases where a > >>>config value affects what are apparently public structs (rte_mbuf wrt > >>>RTE_MBUF_REFCNT for example), which really is a no-go. > >>> > >>Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > >>I'll look into it. > >> > >>>>>>I think the problem is a little bit orthogonal to the libdpdk_core > >>>>>>problem you > >>>>>>were initially addressing. That is to say, this problem of > >>>>>>dlopen-ed PMD's > >>>>>>exists regardless of weather you build the DPDK as part of a static > >>>>>>or dynamic > >>>>>>library. The problems just happen to intersect in their > >>>>>>manipulation of the > >>>>>>DT_NEEDED entries. > >>>>>> > >>>>>>Ok, so, given the above, I would say your approach is likely > >>>>>>correct, just > >>>>>>prevent DT_NEEDED entries from getting added to PMD's. Doing so will > >>>>>>sidestep > >>>>>>loading issue for libraries that may not exist in the filesystem, > >>>>>>but thats ok, > >>>>>>because by all rights, the symbols codified in those needed > >>>>>>libraries should > >>>>>>already be present in the running application (either made available > >>>>>>by the > >>>>>>application having statically linked them, or having the linker load > >>>>>>them from > >>>>>>the proper libraries at run time). > >>>>>My 5c is that I'd much rather see the common case (all static or all > >>>>>shared) > >>>>>be simple and reliable, which in case of DSOs includes no lying > >>>>>(whether by > >>>>>omission or otherwise) about DT_NEEDED, ever. That way the issue is > >>>>>dealt > >>>>>once where it belongs. If somebody wants to go down the rabbit hole of > >>>>>mixed > >>>>>shared + static linkage, let them dig the hole by themselves :) > >>>>> > >>>>This is a fair point. Can DT_NEEDED sections be stripped via tools like > >>>>objcopy > >>>>after the build is complete? If so, end users can hack this corner case > >>>>to work > >>>>as needed. > >>>Patchelf (http://nixos.org/patchelf.html) appears to support that, but > >>>given that source is available it'd be easier to just modify the makefiles > >>>if that's really needed. > >>> > >>I think we agree on the issue. > >> > >>So I'll be sending a patch to add DT_NEEDED entries to all libraries and > >>PMDs. The only exception would be librte_eal, which would not have proper > >>NEEDED entries. > >>Do we bother adding a linker script for librte_eal that would include > >>dependent libraries? > >> > >I say yes to the linker script, but will happily bow to an alternate consensus > >Neil > > > So the case we want to solve is the following circular dependencies: > eal -> mempool, malloc > mempool -> eal , malloc, ring > malloc -> eal > ring -> eal, malloc > > We cannot write/create the proposed (below) linker script at least until we > have built mempool and malloc. > INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) > Not sure I understand why you have a build time dependency on this. Link time perhaps, but not build time. Or am I reading too much into your use of the term 'built' above? > Few ways I have thought about implementing this (not particularly fond of > any of them) : > - Have the linker script file in the repo (scripts/ ?) in a fixed location > and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. > - Generate the file on build time from a defined make variable once all > libs have finished > I'm still not sure I understand. Why does this dependency exist at build time? The dependency between malloc and eal shouldn't be a problem during the build, as symbols from each other should just remain undefined, and get resolved at load time. What is the error you are getting? Best Neil > Thoughts? any other approached is more than welcome! > > Sergio > > PS: Thinking again on the core library and the issue of having multiple > version.map files, we could have a core_version.map instead instead of > multiple files per core library (eal, mempool, etc) > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150222233740.GB31293-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150222233740.GB31293-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> @ 2015-02-23 10:25 ` Gonzalez Monroy, Sergio [not found] ` <54EAFFFD.5000200-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-23 10:25 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 22/02/2015 23:37, Neil Horman wrote: > On Fri, Feb 20, 2015 at 02:31:36PM +0000, Gonzalez Monroy, Sergio wrote: >> On 13/02/2015 12:51, Neil Horman wrote: >>> On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: >>>> On 13/02/2015 10:14, Panu Matilainen wrote: >>>>> On 02/12/2015 05:52 PM, Neil Horman wrote: >>>>>> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>>>>>> On 02/12/2015 02:23 PM, Neil Horman wrote: >>>>> [...snip...] >>>>>>>>>>> So I just realized that I was not having into account a possible >>>>>>>>>>> scenario, where >>>>>>>>>>> we have an app built with static dpdk libs then loading a dso >>>>>>>>>>> with -d >>>>>>>>>>> option. >>>>>>>>>>> >>>>>>>>>>> In such case, because the pmd would have DT_NEEDED entries, >>>>>>>>>>> dlopen will >>>>>>>>>>> fail. >>>>>>>>>>> So to enable such scenario we would need to build PMDs without >>>>>>>>>>> DT_NEEDED >>>>>>>>>>> entries. >>>>>>>>>> Hmm, for that to be a problem you'd need to have the PMD built >>>>>>>>>> against >>>>>>>>>> shared dpdk libs and while the application is built against >>>>>>>>>> static dpdk >>>>>>>>>> libs. I dont think that's a supportable scenario in any case. >>>>>>>>>> >>>>>>>>>> Or is there some other scenario that I'm not seeing? >>>>>>>>>> >>>>>>>>>> - Panu - >>>>>>>>>> >>>>>>>>> I agree with you. I suppose it comes down to, do we want to >>>>>>>>> support such >>>>>>>>> scenario? >>>>>>>>> >>>>>>>>> From what I can see, it seems that we do currently support such >>>>>>>>> scenario by >>>>>>>>> building dpdk apps against all static dpdk libs using >>>>>>>>> --whole-archive (all >>>>>>>>> libs and not only PMDs). >>>>>>>>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>>>>>>>> >>>>>>>>> >>>>>>>>> Am I misunderstanding this? >>>>>>>>> >>>>>>>> Shoot, you're right, I missed the static build aspect to this. Yes, >>>>>>>> if we do the following: >>>>>>>> >>>>>>>> 1) Build the DPDK as a static library >>>>>>>> 2) Link an application against (1) >>>>>>>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>>>>>>> >>>>>>>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >>>>>>>> the shared >>>>>>>> objects on which it (the PMD) depends will not exist in the file >>>>>>>> system. >>>>>>> I think its even more twisty: >>>>>>> >>>>>>> 1) Build the DPDK as a static library >>>>>>> 2) Link an application against (1) >>>>>>> 3) Do another build of DPDK as a shared library >>>>>>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>>>>>> of or >>>>>>> against 3) >>>>>>> >>>>>>> Somehow I doubt this would work very well. >>>>>>> >>>>>> Ideally it should, presuming the ABI is preserved between (1) and (3), >>>>>> though I >>>>>> agree, up until recently, that was an assumption that was unreliable. >>>>> Versioning is a big and important step towards reliability but there are >>>>> more issues to solve. This of course getting pretty far from the original >>>>> topic, but at least one such issue is that there are some cases where a >>>>> config value affects what are apparently public structs (rte_mbuf wrt >>>>> RTE_MBUF_REFCNT for example), which really is a no-go. >>>>> >>>> Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. >>>> I'll look into it. >>>> >>>>>>>> I think the problem is a little bit orthogonal to the libdpdk_core >>>>>>>> problem you >>>>>>>> were initially addressing. That is to say, this problem of >>>>>>>> dlopen-ed PMD's >>>>>>>> exists regardless of weather you build the DPDK as part of a static >>>>>>>> or dynamic >>>>>>>> library. The problems just happen to intersect in their >>>>>>>> manipulation of the >>>>>>>> DT_NEEDED entries. >>>>>>>> >>>>>>>> Ok, so, given the above, I would say your approach is likely >>>>>>>> correct, just >>>>>>>> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >>>>>>>> sidestep >>>>>>>> loading issue for libraries that may not exist in the filesystem, >>>>>>>> but thats ok, >>>>>>>> because by all rights, the symbols codified in those needed >>>>>>>> libraries should >>>>>>>> already be present in the running application (either made available >>>>>>>> by the >>>>>>>> application having statically linked them, or having the linker load >>>>>>>> them from >>>>>>>> the proper libraries at run time). >>>>>>> My 5c is that I'd much rather see the common case (all static or all >>>>>>> shared) >>>>>>> be simple and reliable, which in case of DSOs includes no lying >>>>>>> (whether by >>>>>>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>>>>>> dealt >>>>>>> once where it belongs. If somebody wants to go down the rabbit hole of >>>>>>> mixed >>>>>>> shared + static linkage, let them dig the hole by themselves :) >>>>>>> >>>>>> This is a fair point. Can DT_NEEDED sections be stripped via tools like >>>>>> objcopy >>>>>> after the build is complete? If so, end users can hack this corner case >>>>>> to work >>>>>> as needed. >>>>> Patchelf (http://nixos.org/patchelf.html) appears to support that, but >>>>> given that source is available it'd be easier to just modify the makefiles >>>>> if that's really needed. >>>>> >>>> I think we agree on the issue. >>>> >>>> So I'll be sending a patch to add DT_NEEDED entries to all libraries and >>>> PMDs. The only exception would be librte_eal, which would not have proper >>>> NEEDED entries. >>>> Do we bother adding a linker script for librte_eal that would include >>>> dependent libraries? >>>> >>> I say yes to the linker script, but will happily bow to an alternate consensus >>> Neil >>> >> So the case we want to solve is the following circular dependencies: >> eal -> mempool, malloc >> mempool -> eal , malloc, ring >> malloc -> eal >> ring -> eal, malloc >> >> We cannot write/create the proposed (below) linker script at least until we >> have built mempool and malloc. >> INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) >> > Not sure I understand why you have a build time dependency on this. Link time > perhaps, but not build time. Or am I reading too much into your use of the term > 'built' above? I meant 'built' as compiled + linked. Am I misusing the term? >> Few ways I have thought about implementing this (not particularly fond of >> any of them) : >> - Have the linker script file in the repo (scripts/ ?) in a fixed location >> and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. >> - Generate the file on build time from a defined make variable once all >> libs have finished >> > I'm still not sure I understand. Why does this dependency exist at build time? > The dependency between malloc and eal shouldn't be a problem during the build, > as symbols from each other should just remain undefined, and get resolved at > load time. Is that not the way it is currently implemented? I get the impression that we are talking about different goals (correct me if it is not the case) I thought that the agreed solution was to: 1) NOT to create/generate a 'core' library 2) Add DT_NEEDED entries for all libraries (except eal which is the first library we link) 3) Use linker script for eal Given the previously mentioned circular dependencies between eal, mempool, malloc and ring: - eal would not be linked against other libraries (no NEEDED entries) - malloc is linked against eal (previously built), so malloc would have a NEEDED entry for eal. In that scenario, if the linker script is setup/created after we build eal, then when we try to link malloc against eal, the linker will pull mempool and malloc too (because we included them in the linker script). Therefore, the link fails as none of those libraries (malloc and mempool) have been built yet. Was your suggestion to leave all of these libraries (eal, mempool, malloc, ring) without NEEDED entries? Regards, Sergio > What is the error you are getting? > > Best > Neil > >> Thoughts? any other approached is more than welcome! >> >> Sergio >> >> PS: Thinking again on the core library and the issue of having multiple >> version.map files, we could have a core_version.map instead instead of >> multiple files per core library (eal, mempool, etc) >> >> ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54EAFFFD.5000200-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54EAFFFD.5000200-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-02-23 13:52 ` Neil Horman [not found] ` <20150223135205.GA19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-23 13:52 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Mon, Feb 23, 2015 at 10:25:01AM +0000, Gonzalez Monroy, Sergio wrote: > On 22/02/2015 23:37, Neil Horman wrote: > >On Fri, Feb 20, 2015 at 02:31:36PM +0000, Gonzalez Monroy, Sergio wrote: > >>On 13/02/2015 12:51, Neil Horman wrote: > >>>On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: > >>>>On 13/02/2015 10:14, Panu Matilainen wrote: > >>>>>On 02/12/2015 05:52 PM, Neil Horman wrote: > >>>>>>On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >>>>>>>On 02/12/2015 02:23 PM, Neil Horman wrote: > >>>>>[...snip...] > >>>>>>>>>>>So I just realized that I was not having into account a possible > >>>>>>>>>>>scenario, where > >>>>>>>>>>>we have an app built with static dpdk libs then loading a dso > >>>>>>>>>>>with -d > >>>>>>>>>>>option. > >>>>>>>>>>> > >>>>>>>>>>>In such case, because the pmd would have DT_NEEDED entries, > >>>>>>>>>>>dlopen will > >>>>>>>>>>>fail. > >>>>>>>>>>>So to enable such scenario we would need to build PMDs without > >>>>>>>>>>>DT_NEEDED > >>>>>>>>>>>entries. > >>>>>>>>>>Hmm, for that to be a problem you'd need to have the PMD built > >>>>>>>>>>against > >>>>>>>>>>shared dpdk libs and while the application is built against > >>>>>>>>>>static dpdk > >>>>>>>>>>libs. I dont think that's a supportable scenario in any case. > >>>>>>>>>> > >>>>>>>>>>Or is there some other scenario that I'm not seeing? > >>>>>>>>>> > >>>>>>>>>> - Panu - > >>>>>>>>>> > >>>>>>>>>I agree with you. I suppose it comes down to, do we want to > >>>>>>>>>support such > >>>>>>>>>scenario? > >>>>>>>>> > >>>>>>>>> From what I can see, it seems that we do currently support such > >>>>>>>>>scenario by > >>>>>>>>>building dpdk apps against all static dpdk libs using > >>>>>>>>>--whole-archive (all > >>>>>>>>>libs and not only PMDs). > >>>>>>>>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>Am I misunderstanding this? > >>>>>>>>> > >>>>>>>>Shoot, you're right, I missed the static build aspect to this. Yes, > >>>>>>>>if we do the following: > >>>>>>>> > >>>>>>>>1) Build the DPDK as a static library > >>>>>>>>2) Link an application against (1) > >>>>>>>>3) Use the dlopen mechanism to load a PMD built as a DSO > >>>>>>>> > >>>>>>>>Then the DT_NEEDED entries in the DSO will go unsatisfied, because > >>>>>>>>the shared > >>>>>>>>objects on which it (the PMD) depends will not exist in the file > >>>>>>>>system. > >>>>>>>I think its even more twisty: > >>>>>>> > >>>>>>>1) Build the DPDK as a static library > >>>>>>>2) Link an application against (1) > >>>>>>>3) Do another build of DPDK as a shared library > >>>>>>>4) In app 2), use the dlopen mechanism to load a PMD built as a part > >>>>>>>of or > >>>>>>>against 3) > >>>>>>> > >>>>>>>Somehow I doubt this would work very well. > >>>>>>> > >>>>>>Ideally it should, presuming the ABI is preserved between (1) and (3), > >>>>>>though I > >>>>>>agree, up until recently, that was an assumption that was unreliable. > >>>>>Versioning is a big and important step towards reliability but there are > >>>>>more issues to solve. This of course getting pretty far from the original > >>>>>topic, but at least one such issue is that there are some cases where a > >>>>>config value affects what are apparently public structs (rte_mbuf wrt > >>>>>RTE_MBUF_REFCNT for example), which really is a no-go. > >>>>> > >>>>Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > >>>>I'll look into it. > >>>> > >>>>>>>>I think the problem is a little bit orthogonal to the libdpdk_core > >>>>>>>>problem you > >>>>>>>>were initially addressing. That is to say, this problem of > >>>>>>>>dlopen-ed PMD's > >>>>>>>>exists regardless of weather you build the DPDK as part of a static > >>>>>>>>or dynamic > >>>>>>>>library. The problems just happen to intersect in their > >>>>>>>>manipulation of the > >>>>>>>>DT_NEEDED entries. > >>>>>>>> > >>>>>>>>Ok, so, given the above, I would say your approach is likely > >>>>>>>>correct, just > >>>>>>>>prevent DT_NEEDED entries from getting added to PMD's. Doing so will > >>>>>>>>sidestep > >>>>>>>>loading issue for libraries that may not exist in the filesystem, > >>>>>>>>but thats ok, > >>>>>>>>because by all rights, the symbols codified in those needed > >>>>>>>>libraries should > >>>>>>>>already be present in the running application (either made available > >>>>>>>>by the > >>>>>>>>application having statically linked them, or having the linker load > >>>>>>>>them from > >>>>>>>>the proper libraries at run time). > >>>>>>>My 5c is that I'd much rather see the common case (all static or all > >>>>>>>shared) > >>>>>>>be simple and reliable, which in case of DSOs includes no lying > >>>>>>>(whether by > >>>>>>>omission or otherwise) about DT_NEEDED, ever. That way the issue is > >>>>>>>dealt > >>>>>>>once where it belongs. If somebody wants to go down the rabbit hole of > >>>>>>>mixed > >>>>>>>shared + static linkage, let them dig the hole by themselves :) > >>>>>>> > >>>>>>This is a fair point. Can DT_NEEDED sections be stripped via tools like > >>>>>>objcopy > >>>>>>after the build is complete? If so, end users can hack this corner case > >>>>>>to work > >>>>>>as needed. > >>>>>Patchelf (http://nixos.org/patchelf.html) appears to support that, but > >>>>>given that source is available it'd be easier to just modify the makefiles > >>>>>if that's really needed. > >>>>> > >>>>I think we agree on the issue. > >>>> > >>>>So I'll be sending a patch to add DT_NEEDED entries to all libraries and > >>>>PMDs. The only exception would be librte_eal, which would not have proper > >>>>NEEDED entries. > >>>>Do we bother adding a linker script for librte_eal that would include > >>>>dependent libraries? > >>>> > >>>I say yes to the linker script, but will happily bow to an alternate consensus > >>>Neil > >>> > >>So the case we want to solve is the following circular dependencies: > >>eal -> mempool, malloc > >>mempool -> eal , malloc, ring > >>malloc -> eal > >>ring -> eal, malloc > >> > >>We cannot write/create the proposed (below) linker script at least until we > >>have built mempool and malloc. > >>INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) > >> > >Not sure I understand why you have a build time dependency on this. Link time > >perhaps, but not build time. Or am I reading too much into your use of the term > >'built' above? > I meant 'built' as compiled + linked. Am I misusing the term? No, you're not (though I misused the term link time above, I meant to say load time). So you're saying that when you build shared libraries, you get linker errors indicating that, during the build, you're missing symbols, is that correct? I guess I'm confused because I don't see how thats not happening for everyone, right now. In other words, I'm not sure what about your changes is giving rise to that problem. > >>Few ways I have thought about implementing this (not particularly fond of > >>any of them) : > >> - Have the linker script file in the repo (scripts/ ?) in a fixed location > >>and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. > >> - Generate the file on build time from a defined make variable once all > >>libs have finished > >> > >I'm still not sure I understand. Why does this dependency exist at build time? > >The dependency between malloc and eal shouldn't be a problem during the build, > >as symbols from each other should just remain undefined, and get resolved at > >load time. > Is that not the way it is currently implemented? > I get the impression that we are talking about different goals (correct me > if it is not the case) > We may well be, I'm not sure yet. > I thought that the agreed solution was to: > 1) NOT to create/generate a 'core' library > 2) Add DT_NEEDED entries for all libraries (except eal which is the first > library we link) > 3) Use linker script for eal > Ok, we're definately on the same page, as thats what I thought the goal was as well. > Given the previously mentioned circular dependencies between eal, mempool, > malloc and ring: > - eal would not be linked against other libraries (no NEEDED entries) > - malloc is linked against eal (previously built), so malloc would have a > NEEDED entry for eal. > > In that scenario, if the linker script is setup/created after we build eal, > then when we try to link malloc > against eal, the linker will pull mempool and malloc too (because we > included them in the linker script). > Therefore, the link fails as none of those libraries (malloc and mempool) > have been built yet. > Ah, I see now, I wasn't thinking about the extra requirements that DT_NEEDED entries placed on the build conditions. I see now, apologies for being dense previously. Given what you indicate I would say that the solution here is to link the libraries against individual other specific libraries, not the core library that you generate as a linker script. That way you avoid the circular dependency, and the core library just becomes a convienience for application developers looking to link to a single library. Neil > Was your suggestion to leave all of these libraries (eal, mempool, malloc, > ring) without NEEDED entries? > No, you can add NEEDED entries there, they will just be for the individual libraries, not the core linker script library. Best Neil > Regards, > Sergio > >What is the error you are getting? > > > >Best > >Neil > > > >>Thoughts? any other approached is more than welcome! > >> > >>Sergio > >> > >>PS: Thinking again on the core library and the issue of having multiple > >>version.map files, we could have a core_version.map instead instead of > >>multiple files per core library (eal, mempool, etc) > >> > >> > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150223135205.GA19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150223135205.GA19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-02-23 14:58 ` Gonzalez Monroy, Sergio [not found] ` <54EB4016.1040204-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-23 14:58 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 23/02/2015 13:52, Neil Horman wrote: > On Mon, Feb 23, 2015 at 10:25:01AM +0000, Gonzalez Monroy, Sergio wrote: >> On 22/02/2015 23:37, Neil Horman wrote: >>> On Fri, Feb 20, 2015 at 02:31:36PM +0000, Gonzalez Monroy, Sergio wrote: >>>> On 13/02/2015 12:51, Neil Horman wrote: >>>>> On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: >>>>>> On 13/02/2015 10:14, Panu Matilainen wrote: >>>>>>> On 02/12/2015 05:52 PM, Neil Horman wrote: >>>>>>>> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>>>>>>>> On 02/12/2015 02:23 PM, Neil Horman wrote: >>>>>>> [...snip...] >>>>>>>>>>>>> So I just realized that I was not having into account a possible >>>>>>>>>>>>> scenario, where >>>>>>>>>>>>> we have an app built with static dpdk libs then loading a dso >>>>>>>>>>>>> with -d >>>>>>>>>>>>> option. >>>>>>>>>>>>> >>>>>>>>>>>>> In such case, because the pmd would have DT_NEEDED entries, >>>>>>>>>>>>> dlopen will >>>>>>>>>>>>> fail. >>>>>>>>>>>>> So to enable such scenario we would need to build PMDs without >>>>>>>>>>>>> DT_NEEDED >>>>>>>>>>>>> entries. >>>>>>>>>>>> Hmm, for that to be a problem you'd need to have the PMD built >>>>>>>>>>>> against >>>>>>>>>>>> shared dpdk libs and while the application is built against >>>>>>>>>>>> static dpdk >>>>>>>>>>>> libs. I dont think that's a supportable scenario in any case. >>>>>>>>>>>> >>>>>>>>>>>> Or is there some other scenario that I'm not seeing? >>>>>>>>>>>> >>>>>>>>>>>> - Panu - >>>>>>>>>>>> >>>>>>>>>>> I agree with you. I suppose it comes down to, do we want to >>>>>>>>>>> support such >>>>>>>>>>> scenario? >>>>>>>>>>> >>>>>>>>>>> From what I can see, it seems that we do currently support such >>>>>>>>>>> scenario by >>>>>>>>>>> building dpdk apps against all static dpdk libs using >>>>>>>>>>> --whole-archive (all >>>>>>>>>>> libs and not only PMDs). >>>>>>>>>>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Am I misunderstanding this? >>>>>>>>>>> >>>>>>>>>> Shoot, you're right, I missed the static build aspect to this. Yes, >>>>>>>>>> if we do the following: >>>>>>>>>> >>>>>>>>>> 1) Build the DPDK as a static library >>>>>>>>>> 2) Link an application against (1) >>>>>>>>>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>>>>>>>>> >>>>>>>>>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >>>>>>>>>> the shared >>>>>>>>>> objects on which it (the PMD) depends will not exist in the file >>>>>>>>>> system. >>>>>>>>> I think its even more twisty: >>>>>>>>> >>>>>>>>> 1) Build the DPDK as a static library >>>>>>>>> 2) Link an application against (1) >>>>>>>>> 3) Do another build of DPDK as a shared library >>>>>>>>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>>>>>>>> of or >>>>>>>>> against 3) >>>>>>>>> >>>>>>>>> Somehow I doubt this would work very well. >>>>>>>>> >>>>>>>> Ideally it should, presuming the ABI is preserved between (1) and (3), >>>>>>>> though I >>>>>>>> agree, up until recently, that was an assumption that was unreliable. >>>>>>> Versioning is a big and important step towards reliability but there are >>>>>>> more issues to solve. This of course getting pretty far from the original >>>>>>> topic, but at least one such issue is that there are some cases where a >>>>>>> config value affects what are apparently public structs (rte_mbuf wrt >>>>>>> RTE_MBUF_REFCNT for example), which really is a no-go. >>>>>>> >>>>>> Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. >>>>>> I'll look into it. >>>>>> >>>>>>>>>> I think the problem is a little bit orthogonal to the libdpdk_core >>>>>>>>>> problem you >>>>>>>>>> were initially addressing. That is to say, this problem of >>>>>>>>>> dlopen-ed PMD's >>>>>>>>>> exists regardless of weather you build the DPDK as part of a static >>>>>>>>>> or dynamic >>>>>>>>>> library. The problems just happen to intersect in their >>>>>>>>>> manipulation of the >>>>>>>>>> DT_NEEDED entries. >>>>>>>>>> >>>>>>>>>> Ok, so, given the above, I would say your approach is likely >>>>>>>>>> correct, just >>>>>>>>>> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >>>>>>>>>> sidestep >>>>>>>>>> loading issue for libraries that may not exist in the filesystem, >>>>>>>>>> but thats ok, >>>>>>>>>> because by all rights, the symbols codified in those needed >>>>>>>>>> libraries should >>>>>>>>>> already be present in the running application (either made available >>>>>>>>>> by the >>>>>>>>>> application having statically linked them, or having the linker load >>>>>>>>>> them from >>>>>>>>>> the proper libraries at run time). >>>>>>>>> My 5c is that I'd much rather see the common case (all static or all >>>>>>>>> shared) >>>>>>>>> be simple and reliable, which in case of DSOs includes no lying >>>>>>>>> (whether by >>>>>>>>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>>>>>>>> dealt >>>>>>>>> once where it belongs. If somebody wants to go down the rabbit hole of >>>>>>>>> mixed >>>>>>>>> shared + static linkage, let them dig the hole by themselves :) >>>>>>>>> >>>>>>>> This is a fair point. Can DT_NEEDED sections be stripped via tools like >>>>>>>> objcopy >>>>>>>> after the build is complete? If so, end users can hack this corner case >>>>>>>> to work >>>>>>>> as needed. >>>>>>> Patchelf (http://nixos.org/patchelf.html) appears to support that, but >>>>>>> given that source is available it'd be easier to just modify the makefiles >>>>>>> if that's really needed. >>>>>>> >>>>>> I think we agree on the issue. >>>>>> >>>>>> So I'll be sending a patch to add DT_NEEDED entries to all libraries and >>>>>> PMDs. The only exception would be librte_eal, which would not have proper >>>>>> NEEDED entries. >>>>>> Do we bother adding a linker script for librte_eal that would include >>>>>> dependent libraries? >>>>>> >>>>> I say yes to the linker script, but will happily bow to an alternate consensus >>>>> Neil >>>>> >>>> So the case we want to solve is the following circular dependencies: >>>> eal -> mempool, malloc >>>> mempool -> eal , malloc, ring >>>> malloc -> eal >>>> ring -> eal, malloc >>>> >>>> We cannot write/create the proposed (below) linker script at least until we >>>> have built mempool and malloc. >>>> INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) >>>> >>> Not sure I understand why you have a build time dependency on this. Link time >>> perhaps, but not build time. Or am I reading too much into your use of the term >>> 'built' above? >> I meant 'built' as compiled + linked. Am I misusing the term? > No, you're not (though I misused the term link time above, I meant to say load > time). So you're saying that when you build shared libraries, you get linker > errors indicating that, during the build, you're missing symbols, is that > correct? I guess I'm confused because I don't see how thats not happening for > everyone, right now. In other words, I'm not sure what about your changes is > giving rise to that problem. > >>>> Few ways I have thought about implementing this (not particularly fond of >>>> any of them) : >>>> - Have the linker script file in the repo (scripts/ ?) in a fixed location >>>> and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. >>>> - Generate the file on build time from a defined make variable once all >>>> libs have finished >>>> >>> I'm still not sure I understand. Why does this dependency exist at build time? >>> The dependency between malloc and eal shouldn't be a problem during the build, >>> as symbols from each other should just remain undefined, and get resolved at >>> load time. >> Is that not the way it is currently implemented? >> I get the impression that we are talking about different goals (correct me >> if it is not the case) >> > We may well be, I'm not sure yet. > >> I thought that the agreed solution was to: >> 1) NOT to create/generate a 'core' library >> 2) Add DT_NEEDED entries for all libraries (except eal which is the first >> library we link) >> 3) Use linker script for eal >> > Ok, we're definately on the same page, as thats what I thought the goal was as > well. > >> Given the previously mentioned circular dependencies between eal, mempool, >> malloc and ring: >> - eal would not be linked against other libraries (no NEEDED entries) >> - malloc is linked against eal (previously built), so malloc would have a >> NEEDED entry for eal. >> >> In that scenario, if the linker script is setup/created after we build eal, >> then when we try to link malloc >> against eal, the linker will pull mempool and malloc too (because we >> included them in the linker script). >> Therefore, the link fails as none of those libraries (malloc and mempool) >> have been built yet. >> > Ah, I see now, I wasn't thinking about the extra requirements that DT_NEEDED > entries placed on the build conditions. > > I see now, apologies for being dense previously. Given what you indicate I > would say that the solution here is to link the libraries against individual > other specific libraries, not the core library that you generate as a linker > script. That way you avoid the circular dependency, and the core library just > becomes a convienience for application developers looking to link to a single > library. > I'm not sure I quite understand your suggestion. Could you roughly describe steps for building eal, malloc and mempool libs ? For example, something like this? 1) build eal, which creates librte_eal.so.1 2) write linker script for librte_eal.so 3) build malloc against eal (-lrte_eal ) etc I suppose that another way to go about this, instead of creating the linker script that pulls dependent libraries, is to always link (using --no-as-needed in case gcc adds it by default) against these libraries (eal, mempool, malloc, and ring) with necessary doc about how to build apps. Sergio > Neil > >> Was your suggestion to leave all of these libraries (eal, mempool, malloc, >> ring) without NEEDED entries? >> > No, you can add NEEDED entries there, they will just be for the individual > libraries, not the core linker script library. > > Best > Neil > >> Regards, >> Sergio >>> What is the error you are getting? >>> >>> Best >>> Neil >>> >>>> Thoughts? any other approached is more than welcome! >>>> >>>> Sergio >>>> >>>> PS: Thinking again on the core library and the issue of having multiple >>>> version.map files, we could have a core_version.map instead instead of >>>> multiple files per core library (eal, mempool, etc) >>>> >>>> >> >> ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <54EB4016.1040204-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <54EB4016.1040204-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-02-23 18:23 ` Neil Horman [not found] ` <20150223182319.GC19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-02-23 18:23 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Mon, Feb 23, 2015 at 02:58:30PM +0000, Gonzalez Monroy, Sergio wrote: > On 23/02/2015 13:52, Neil Horman wrote: > >On Mon, Feb 23, 2015 at 10:25:01AM +0000, Gonzalez Monroy, Sergio wrote: > >>On 22/02/2015 23:37, Neil Horman wrote: > >>>On Fri, Feb 20, 2015 at 02:31:36PM +0000, Gonzalez Monroy, Sergio wrote: > >>>>On 13/02/2015 12:51, Neil Horman wrote: > >>>>>On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: > >>>>>>On 13/02/2015 10:14, Panu Matilainen wrote: > >>>>>>>On 02/12/2015 05:52 PM, Neil Horman wrote: > >>>>>>>>On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >>>>>>>>>On 02/12/2015 02:23 PM, Neil Horman wrote: > >>>>>>>[...snip...] > >>>>>>>>>>>>>So I just realized that I was not having into account a possible > >>>>>>>>>>>>>scenario, where > >>>>>>>>>>>>>we have an app built with static dpdk libs then loading a dso > >>>>>>>>>>>>>with -d > >>>>>>>>>>>>>option. > >>>>>>>>>>>>> > >>>>>>>>>>>>>In such case, because the pmd would have DT_NEEDED entries, > >>>>>>>>>>>>>dlopen will > >>>>>>>>>>>>>fail. > >>>>>>>>>>>>>So to enable such scenario we would need to build PMDs without > >>>>>>>>>>>>>DT_NEEDED > >>>>>>>>>>>>>entries. > >>>>>>>>>>>>Hmm, for that to be a problem you'd need to have the PMD built > >>>>>>>>>>>>against > >>>>>>>>>>>>shared dpdk libs and while the application is built against > >>>>>>>>>>>>static dpdk > >>>>>>>>>>>>libs. I dont think that's a supportable scenario in any case. > >>>>>>>>>>>> > >>>>>>>>>>>>Or is there some other scenario that I'm not seeing? > >>>>>>>>>>>> > >>>>>>>>>>>> - Panu - > >>>>>>>>>>>> > >>>>>>>>>>>I agree with you. I suppose it comes down to, do we want to > >>>>>>>>>>>support such > >>>>>>>>>>>scenario? > >>>>>>>>>>> > >>>>>>>>>>> From what I can see, it seems that we do currently support such > >>>>>>>>>>>scenario by > >>>>>>>>>>>building dpdk apps against all static dpdk libs using > >>>>>>>>>>>--whole-archive (all > >>>>>>>>>>>libs and not only PMDs). > >>>>>>>>>>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>Am I misunderstanding this? > >>>>>>>>>>> > >>>>>>>>>>Shoot, you're right, I missed the static build aspect to this. Yes, > >>>>>>>>>>if we do the following: > >>>>>>>>>> > >>>>>>>>>>1) Build the DPDK as a static library > >>>>>>>>>>2) Link an application against (1) > >>>>>>>>>>3) Use the dlopen mechanism to load a PMD built as a DSO > >>>>>>>>>> > >>>>>>>>>>Then the DT_NEEDED entries in the DSO will go unsatisfied, because > >>>>>>>>>>the shared > >>>>>>>>>>objects on which it (the PMD) depends will not exist in the file > >>>>>>>>>>system. > >>>>>>>>>I think its even more twisty: > >>>>>>>>> > >>>>>>>>>1) Build the DPDK as a static library > >>>>>>>>>2) Link an application against (1) > >>>>>>>>>3) Do another build of DPDK as a shared library > >>>>>>>>>4) In app 2), use the dlopen mechanism to load a PMD built as a part > >>>>>>>>>of or > >>>>>>>>>against 3) > >>>>>>>>> > >>>>>>>>>Somehow I doubt this would work very well. > >>>>>>>>> > >>>>>>>>Ideally it should, presuming the ABI is preserved between (1) and (3), > >>>>>>>>though I > >>>>>>>>agree, up until recently, that was an assumption that was unreliable. > >>>>>>>Versioning is a big and important step towards reliability but there are > >>>>>>>more issues to solve. This of course getting pretty far from the original > >>>>>>>topic, but at least one such issue is that there are some cases where a > >>>>>>>config value affects what are apparently public structs (rte_mbuf wrt > >>>>>>>RTE_MBUF_REFCNT for example), which really is a no-go. > >>>>>>> > >>>>>>Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > >>>>>>I'll look into it. > >>>>>> > >>>>>>>>>>I think the problem is a little bit orthogonal to the libdpdk_core > >>>>>>>>>>problem you > >>>>>>>>>>were initially addressing. That is to say, this problem of > >>>>>>>>>>dlopen-ed PMD's > >>>>>>>>>>exists regardless of weather you build the DPDK as part of a static > >>>>>>>>>>or dynamic > >>>>>>>>>>library. The problems just happen to intersect in their > >>>>>>>>>>manipulation of the > >>>>>>>>>>DT_NEEDED entries. > >>>>>>>>>> > >>>>>>>>>>Ok, so, given the above, I would say your approach is likely > >>>>>>>>>>correct, just > >>>>>>>>>>prevent DT_NEEDED entries from getting added to PMD's. Doing so will > >>>>>>>>>>sidestep > >>>>>>>>>>loading issue for libraries that may not exist in the filesystem, > >>>>>>>>>>but thats ok, > >>>>>>>>>>because by all rights, the symbols codified in those needed > >>>>>>>>>>libraries should > >>>>>>>>>>already be present in the running application (either made available > >>>>>>>>>>by the > >>>>>>>>>>application having statically linked them, or having the linker load > >>>>>>>>>>them from > >>>>>>>>>>the proper libraries at run time). > >>>>>>>>>My 5c is that I'd much rather see the common case (all static or all > >>>>>>>>>shared) > >>>>>>>>>be simple and reliable, which in case of DSOs includes no lying > >>>>>>>>>(whether by > >>>>>>>>>omission or otherwise) about DT_NEEDED, ever. That way the issue is > >>>>>>>>>dealt > >>>>>>>>>once where it belongs. If somebody wants to go down the rabbit hole of > >>>>>>>>>mixed > >>>>>>>>>shared + static linkage, let them dig the hole by themselves :) > >>>>>>>>> > >>>>>>>>This is a fair point. Can DT_NEEDED sections be stripped via tools like > >>>>>>>>objcopy > >>>>>>>>after the build is complete? If so, end users can hack this corner case > >>>>>>>>to work > >>>>>>>>as needed. > >>>>>>>Patchelf (http://nixos.org/patchelf.html) appears to support that, but > >>>>>>>given that source is available it'd be easier to just modify the makefiles > >>>>>>>if that's really needed. > >>>>>>> > >>>>>>I think we agree on the issue. > >>>>>> > >>>>>>So I'll be sending a patch to add DT_NEEDED entries to all libraries and > >>>>>>PMDs. The only exception would be librte_eal, which would not have proper > >>>>>>NEEDED entries. > >>>>>>Do we bother adding a linker script for librte_eal that would include > >>>>>>dependent libraries? > >>>>>> > >>>>>I say yes to the linker script, but will happily bow to an alternate consensus > >>>>>Neil > >>>>> > >>>>So the case we want to solve is the following circular dependencies: > >>>>eal -> mempool, malloc > >>>>mempool -> eal , malloc, ring > >>>>malloc -> eal > >>>>ring -> eal, malloc > >>>> > >>>>We cannot write/create the proposed (below) linker script at least until we > >>>>have built mempool and malloc. > >>>>INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) > >>>> > >>>Not sure I understand why you have a build time dependency on this. Link time > >>>perhaps, but not build time. Or am I reading too much into your use of the term > >>>'built' above? > >>I meant 'built' as compiled + linked. Am I misusing the term? > >No, you're not (though I misused the term link time above, I meant to say load > >time). So you're saying that when you build shared libraries, you get linker > >errors indicating that, during the build, you're missing symbols, is that > >correct? I guess I'm confused because I don't see how thats not happening for > >everyone, right now. In other words, I'm not sure what about your changes is > >giving rise to that problem. > > > >>>>Few ways I have thought about implementing this (not particularly fond of > >>>>any of them) : > >>>> - Have the linker script file in the repo (scripts/ ?) in a fixed location > >>>>and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. > >>>> - Generate the file on build time from a defined make variable once all > >>>>libs have finished > >>>> > >>>I'm still not sure I understand. Why does this dependency exist at build time? > >>>The dependency between malloc and eal shouldn't be a problem during the build, > >>>as symbols from each other should just remain undefined, and get resolved at > >>>load time. > >>Is that not the way it is currently implemented? > >>I get the impression that we are talking about different goals (correct me > >>if it is not the case) > >> > >We may well be, I'm not sure yet. > > > >>I thought that the agreed solution was to: > >>1) NOT to create/generate a 'core' library > >>2) Add DT_NEEDED entries for all libraries (except eal which is the first > >>library we link) > >>3) Use linker script for eal > >> > >Ok, we're definately on the same page, as thats what I thought the goal was as > >well. > > > >>Given the previously mentioned circular dependencies between eal, mempool, > >>malloc and ring: > >>- eal would not be linked against other libraries (no NEEDED entries) > >>- malloc is linked against eal (previously built), so malloc would have a > >>NEEDED entry for eal. > >> > >>In that scenario, if the linker script is setup/created after we build eal, > >>then when we try to link malloc > >>against eal, the linker will pull mempool and malloc too (because we > >>included them in the linker script). > >>Therefore, the link fails as none of those libraries (malloc and mempool) > >>have been built yet. > >> > >Ah, I see now, I wasn't thinking about the extra requirements that DT_NEEDED > >entries placed on the build conditions. > > > >I see now, apologies for being dense previously. Given what you indicate I > >would say that the solution here is to link the libraries against individual > >other specific libraries, not the core library that you generate as a linker > >script. That way you avoid the circular dependency, and the core library just > >becomes a convienience for application developers looking to link to a single > >library. > > > I'm not sure I quite understand your suggestion. > > Could you roughly describe steps for building eal, malloc and mempool libs ? > For example, something like this? > 1) build eal, which creates librte_eal.so.1 > 2) write linker script for librte_eal.so > 3) build malloc against eal (-lrte_eal ) > etc Hm, so I spent a bit of time looking at this, and your right, I thought this was really just a artifact of the introduction of --as-needed to the build to force DT_NEEDED entries, and my suggestion was that you simply not link the libraries that were causing the circular dependency. I had assumed that the link directives included -lrte_malloc -lrte_mempool for the eal library, but they weren't really needed, so you could remove them and it would work out. Unfortunately that turns out to not be the case. librte_eal does explicitly use calls in librte_malloc, and vice versa. The current use of -no-as-needed in the build system (which I was previously unaware of), is a hack to avoid having to address that problem. That throws a monkey wrench into this plan. I would see 3 ways forward: 1) Fix the problem - That is to say, remove the use of --no-as-needed from the build, and address the circular dependencies that arise. This could/will mean actually merging libraries with circular dependencies into a single library, as they should be so that they can completely resolve all of the symbols they use at link time 2) Ignore the problem. If we just keep the lack of DT_NEEDED entries in place, I think the problem goes away, and we can continue on. I think option 1 is likely the more correct approach, as removing DT_NEEDED to avoid a circuar depenency is a hack, but it may not be the most pragmatic approach. just living without DT_NEEDED entries and documenting link time needs will certainly be faster, and might be the better course of action, especially if we provide a 'core' pseudo library/linker script that embodies that action for the end user. Neil > I suppose that another way to go about this, instead of creating the linker > script that pulls > dependent libraries, is to always link (using --no-as-needed in case gcc > adds it by default) > against these libraries (eal, mempool, malloc, and ring) with necessary doc > about how to build apps. > > Sergio > >Neil > > > >>Was your suggestion to leave all of these libraries (eal, mempool, malloc, > >>ring) without NEEDED entries? > >> > >No, you can add NEEDED entries there, they will just be for the individual > >libraries, not the core linker script library. > > > >Best > >Neil > > > >>Regards, > >>Sergio > >>>What is the error you are getting? > >>> > >>>Best > >>>Neil > >>> > >>>>Thoughts? any other approached is more than welcome! > >>>> > >>>>Sergio > >>>> > >>>>PS: Thinking again on the core library and the issue of having multiple > >>>>version.map files, we could have a core_version.map instead instead of > >>>>multiple files per core library (eal, mempool, etc) > >>>> > >>>> > >> > >> > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150223182319.GC19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH 0/8] Improve build process [not found] ` <20150223182319.GC19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-02-24 13:24 ` Gonzalez Monroy, Sergio 0 siblings, 0 replies; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-02-24 13:24 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 23/02/2015 18:23, Neil Horman wrote: > On Mon, Feb 23, 2015 at 02:58:30PM +0000, Gonzalez Monroy, Sergio wrote: >> On 23/02/2015 13:52, Neil Horman wrote: >>> On Mon, Feb 23, 2015 at 10:25:01AM +0000, Gonzalez Monroy, Sergio wrote: >>>> On 22/02/2015 23:37, Neil Horman wrote: >>>>> On Fri, Feb 20, 2015 at 02:31:36PM +0000, Gonzalez Monroy, Sergio wrote: >>>>>> On 13/02/2015 12:51, Neil Horman wrote: >>>>>>> On Fri, Feb 13, 2015 at 11:08:02AM +0000, Gonzalez Monroy, Sergio wrote: >>>>>>>> On 13/02/2015 10:14, Panu Matilainen wrote: >>>>>>>>> On 02/12/2015 05:52 PM, Neil Horman wrote: >>>>>>>>>> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>>>>>>>>>> On 02/12/2015 02:23 PM, Neil Horman wrote: >>>>>>>>> [...snip...] >>>>>>>>>>>>>>> So I just realized that I was not having into account a possible >>>>>>>>>>>>>>> scenario, where >>>>>>>>>>>>>>> we have an app built with static dpdk libs then loading a dso >>>>>>>>>>>>>>> with -d >>>>>>>>>>>>>>> option. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In such case, because the pmd would have DT_NEEDED entries, >>>>>>>>>>>>>>> dlopen will >>>>>>>>>>>>>>> fail. >>>>>>>>>>>>>>> So to enable such scenario we would need to build PMDs without >>>>>>>>>>>>>>> DT_NEEDED >>>>>>>>>>>>>>> entries. >>>>>>>>>>>>>> Hmm, for that to be a problem you'd need to have the PMD built >>>>>>>>>>>>>> against >>>>>>>>>>>>>> shared dpdk libs and while the application is built against >>>>>>>>>>>>>> static dpdk >>>>>>>>>>>>>> libs. I dont think that's a supportable scenario in any case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Or is there some other scenario that I'm not seeing? >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Panu - >>>>>>>>>>>>>> >>>>>>>>>>>>> I agree with you. I suppose it comes down to, do we want to >>>>>>>>>>>>> support such >>>>>>>>>>>>> scenario? >>>>>>>>>>>>> >>>>>>>>>>>>> From what I can see, it seems that we do currently support such >>>>>>>>>>>>> scenario by >>>>>>>>>>>>> building dpdk apps against all static dpdk libs using >>>>>>>>>>>>> --whole-archive (all >>>>>>>>>>>>> libs and not only PMDs). >>>>>>>>>>>>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am I misunderstanding this? >>>>>>>>>>>>> >>>>>>>>>>>> Shoot, you're right, I missed the static build aspect to this. Yes, >>>>>>>>>>>> if we do the following: >>>>>>>>>>>> >>>>>>>>>>>> 1) Build the DPDK as a static library >>>>>>>>>>>> 2) Link an application against (1) >>>>>>>>>>>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>>>>>>>>>>> >>>>>>>>>>>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >>>>>>>>>>>> the shared >>>>>>>>>>>> objects on which it (the PMD) depends will not exist in the file >>>>>>>>>>>> system. >>>>>>>>>>> I think its even more twisty: >>>>>>>>>>> >>>>>>>>>>> 1) Build the DPDK as a static library >>>>>>>>>>> 2) Link an application against (1) >>>>>>>>>>> 3) Do another build of DPDK as a shared library >>>>>>>>>>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>>>>>>>>>> of or >>>>>>>>>>> against 3) >>>>>>>>>>> >>>>>>>>>>> Somehow I doubt this would work very well. >>>>>>>>>>> >>>>>>>>>> Ideally it should, presuming the ABI is preserved between (1) and (3), >>>>>>>>>> though I >>>>>>>>>> agree, up until recently, that was an assumption that was unreliable. >>>>>>>>> Versioning is a big and important step towards reliability but there are >>>>>>>>> more issues to solve. This of course getting pretty far from the original >>>>>>>>> topic, but at least one such issue is that there are some cases where a >>>>>>>>> config value affects what are apparently public structs (rte_mbuf wrt >>>>>>>>> RTE_MBUF_REFCNT for example), which really is a no-go. >>>>>>>>> >>>>>>>> Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. >>>>>>>> I'll look into it. >>>>>>>> >>>>>>>>>>>> I think the problem is a little bit orthogonal to the libdpdk_core >>>>>>>>>>>> problem you >>>>>>>>>>>> were initially addressing. That is to say, this problem of >>>>>>>>>>>> dlopen-ed PMD's >>>>>>>>>>>> exists regardless of weather you build the DPDK as part of a static >>>>>>>>>>>> or dynamic >>>>>>>>>>>> library. The problems just happen to intersect in their >>>>>>>>>>>> manipulation of the >>>>>>>>>>>> DT_NEEDED entries. >>>>>>>>>>>> >>>>>>>>>>>> Ok, so, given the above, I would say your approach is likely >>>>>>>>>>>> correct, just >>>>>>>>>>>> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >>>>>>>>>>>> sidestep >>>>>>>>>>>> loading issue for libraries that may not exist in the filesystem, >>>>>>>>>>>> but thats ok, >>>>>>>>>>>> because by all rights, the symbols codified in those needed >>>>>>>>>>>> libraries should >>>>>>>>>>>> already be present in the running application (either made available >>>>>>>>>>>> by the >>>>>>>>>>>> application having statically linked them, or having the linker load >>>>>>>>>>>> them from >>>>>>>>>>>> the proper libraries at run time). >>>>>>>>>>> My 5c is that I'd much rather see the common case (all static or all >>>>>>>>>>> shared) >>>>>>>>>>> be simple and reliable, which in case of DSOs includes no lying >>>>>>>>>>> (whether by >>>>>>>>>>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>>>>>>>>>> dealt >>>>>>>>>>> once where it belongs. If somebody wants to go down the rabbit hole of >>>>>>>>>>> mixed >>>>>>>>>>> shared + static linkage, let them dig the hole by themselves :) >>>>>>>>>>> >>>>>>>>>> This is a fair point. Can DT_NEEDED sections be stripped via tools like >>>>>>>>>> objcopy >>>>>>>>>> after the build is complete? If so, end users can hack this corner case >>>>>>>>>> to work >>>>>>>>>> as needed. >>>>>>>>> Patchelf (http://nixos.org/patchelf.html) appears to support that, but >>>>>>>>> given that source is available it'd be easier to just modify the makefiles >>>>>>>>> if that's really needed. >>>>>>>>> >>>>>>>> I think we agree on the issue. >>>>>>>> >>>>>>>> So I'll be sending a patch to add DT_NEEDED entries to all libraries and >>>>>>>> PMDs. The only exception would be librte_eal, which would not have proper >>>>>>>> NEEDED entries. >>>>>>>> Do we bother adding a linker script for librte_eal that would include >>>>>>>> dependent libraries? >>>>>>>> >>>>>>> I say yes to the linker script, but will happily bow to an alternate consensus >>>>>>> Neil >>>>>>> >>>>>> So the case we want to solve is the following circular dependencies: >>>>>> eal -> mempool, malloc >>>>>> mempool -> eal , malloc, ring >>>>>> malloc -> eal >>>>>> ring -> eal, malloc >>>>>> >>>>>> We cannot write/create the proposed (below) linker script at least until we >>>>>> have built mempool and malloc. >>>>>> INPUT ( -lrte_eal.so -lrte_mempool -lrte_malloc ) >>>>>> >>>>> Not sure I understand why you have a build time dependency on this. Link time >>>>> perhaps, but not build time. Or am I reading too much into your use of the term >>>>> 'built' above? >>>> I meant 'built' as compiled + linked. Am I misusing the term? >>> No, you're not (though I misused the term link time above, I meant to say load >>> time). So you're saying that when you build shared libraries, you get linker >>> errors indicating that, during the build, you're missing symbols, is that >>> correct? I guess I'm confused because I don't see how thats not happening for >>> everyone, right now. In other words, I'm not sure what about your changes is >>> giving rise to that problem. >>> >>>>>> Few ways I have thought about implementing this (not particularly fond of >>>>>> any of them) : >>>>>> - Have the linker script file in the repo (scripts/ ?) in a fixed location >>>>>> and just copy it to $(RTE_OUTPUT)/lib/ once all libs have finished building. >>>>>> - Generate the file on build time from a defined make variable once all >>>>>> libs have finished >>>>>> >>>>> I'm still not sure I understand. Why does this dependency exist at build time? >>>>> The dependency between malloc and eal shouldn't be a problem during the build, >>>>> as symbols from each other should just remain undefined, and get resolved at >>>>> load time. >>>> Is that not the way it is currently implemented? >>>> I get the impression that we are talking about different goals (correct me >>>> if it is not the case) >>>> >>> We may well be, I'm not sure yet. >>> >>>> I thought that the agreed solution was to: >>>> 1) NOT to create/generate a 'core' library >>>> 2) Add DT_NEEDED entries for all libraries (except eal which is the first >>>> library we link) >>>> 3) Use linker script for eal >>>> >>> Ok, we're definately on the same page, as thats what I thought the goal was as >>> well. >>> >>>> Given the previously mentioned circular dependencies between eal, mempool, >>>> malloc and ring: >>>> - eal would not be linked against other libraries (no NEEDED entries) >>>> - malloc is linked against eal (previously built), so malloc would have a >>>> NEEDED entry for eal. >>>> >>>> In that scenario, if the linker script is setup/created after we build eal, >>>> then when we try to link malloc >>>> against eal, the linker will pull mempool and malloc too (because we >>>> included them in the linker script). >>>> Therefore, the link fails as none of those libraries (malloc and mempool) >>>> have been built yet. >>>> >>> Ah, I see now, I wasn't thinking about the extra requirements that DT_NEEDED >>> entries placed on the build conditions. >>> >>> I see now, apologies for being dense previously. Given what you indicate I >>> would say that the solution here is to link the libraries against individual >>> other specific libraries, not the core library that you generate as a linker >>> script. That way you avoid the circular dependency, and the core library just >>> becomes a convienience for application developers looking to link to a single >>> library. >>> >> I'm not sure I quite understand your suggestion. >> >> Could you roughly describe steps for building eal, malloc and mempool libs ? >> For example, something like this? >> 1) build eal, which creates librte_eal.so.1 >> 2) write linker script for librte_eal.so >> 3) build malloc against eal (-lrte_eal ) >> etc > Hm, so I spent a bit of time looking at this, and your right, I thought this was > really just a artifact of the introduction of --as-needed to the build to force > DT_NEEDED entries, and my suggestion was that you simply not link the libraries > that were causing the circular dependency. I had assumed that the link > directives included -lrte_malloc -lrte_mempool for the eal library, but they > weren't really needed, so you could remove them and it would work out. > > Unfortunately that turns out to not be the case. librte_eal does explicitly use > calls in librte_malloc, and vice versa. The current use of -no-as-needed in the > build system (which I was previously unaware of), is a hack to avoid having to > address that problem. > > That throws a monkey wrench into this plan. I would see 3 ways forward: > > 1) Fix the problem - That is to say, remove the use of --no-as-needed from the > build, and address the circular dependencies that arise. This could/will mean > actually merging libraries with circular dependencies into a single library, as > they should be so that they can completely resolve all of the symbols they use > at link time > > 2) Ignore the problem. If we just keep the lack of DT_NEEDED entries in place, > I think the problem goes away, and we can continue on. > > I think option 1 is likely the more correct approach, as removing DT_NEEDED to > avoid a circuar depenency is a hack, but it may not be the most pragmatic > approach. just living without DT_NEEDED entries and documenting link time needs > will certainly be faster, and might be the better course of action, especially > if we provide a 'core' pseudo library/linker script that embodies that action > for the end user. > > Neil > So basically for 1) the approach of creating a core library would be a solution. The last suggestion for the core library was to not merge the sources but generate a single library. The problem with that was the versioning wouldn't work as it currently is, given that is per library. So if we were to create a core library, we just need to merge the version.map files of each library into a single version.map for the core library. This approach, as you noted, would be the proper fix. The other solution would be to just leave eal without DT_NEEDED entries and specify in the docs that apps require eal, mempool, malloc and ring to be link such as: --no-as-needed -lrte_eal -lrte_mempool -lrte_malloc -lrte_ring --as-needed With those flags it should work regardless of --as-needed being set before hand. With this second approach we would have all libraries, but eal, with DT_NEEDED entries and we would not need to create a core library. We don't really need to create a linker script for that (not sure we can even create such linker script with those flags) and just documenting link time needs as you mentioned should be enough. So should I go forward with last suggested approach? Regards, Sergio >> I suppose that another way to go about this, instead of creating the linker >> script that pulls >> dependent libraries, is to always link (using --no-as-needed in case gcc >> adds it by default) >> against these libraries (eal, mempool, malloc, and ring) with necessary doc >> about how to build apps. >> >> Sergio >>> Neil >>> >>>> Was your suggestion to leave all of these libraries (eal, mempool, malloc, >>>> ring) without NEEDED entries? >>>> >>> No, you can add NEEDED entries there, they will just be for the individual >>> libraries, not the core linker script library. >>> >>> Best >>> Neil >>> >>>> Regards, >>>> Sergio >>>>> What is the error you are getting? >>>>> >>>>> Best >>>>> Neil >>>>> >>>>>> Thoughts? any other approached is more than welcome! >>>>>> >>>>>> Sergio >>>>>> >>>>>> PS: Thinking again on the core library and the issue of having multiple >>>>>> version.map files, we could have a core_version.map instead instead of >>>>>> multiple files per core library (eal, mempool, etc) >>>>>> >>>>>> >>>> >> >> ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH v2 0/4] Improve build process [not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (8 preceding siblings ...) 2015-01-29 16:38 ` [PATCH 0/8] Improve build process Neil Horman @ 2015-03-12 16:27 ` Sergio Gonzalez Monroy [not found] ` <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 9 siblings, 1 reply; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-03-12 16:27 UTC (permalink / raw) To: dev-VfR2kkLFssw This patch series improves the DPDK build system mostly for shared libraries (and a few nits for static libraries) with the following goals: - Remove config option to build a combined library. - For shared libraries, explicitly link against dependant libraries (adding entries to DT_NEEDED). - Update app linking flags for static/shared DPDK libs. v2: - Do not create a core library to solve circular dependencies between eal, malloc, mempool and ring libraries. Instead, add DT_NEEDED entries for all libraries but eal, then for application linking, always link against these libraries by preceding them with --no-as-needed flag. Sergio Gonzalez Monroy (4): mk: Remove combined library and related options lib: Set LDLIBS for each library mk: Use LDLIBS when linking shared libraries mk: update LDLIBS for app building config/common_bsdapp | 6 -- config/common_linuxapp | 6 -- config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - lib/Makefile | 1 - lib/librte_acl/Makefile | 2 + lib/librte_cfgfile/Makefile | 2 + lib/librte_cmdline/Makefile | 2 + lib/librte_distributor/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 +- mk/rte.app.mk | 63 ++++++++--------- mk/rte.lib.mk | 50 +++----------- mk/rte.sdkbuild.mk | 3 - mk/rte.sharelib.mk | 101 ---------------------------- mk/rte.vars.mk | 9 --- 48 files changed, 131 insertions(+), 209 deletions(-) delete mode 100644 mk/rte.sharelib.mk -- 1.9.3 ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-12 16:27 ` Sergio Gonzalez Monroy [not found] ` <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-12 16:27 ` [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy ` (2 subsequent siblings) 3 siblings, 1 reply; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-03-12 16:27 UTC (permalink / raw) To: dev-VfR2kkLFssw Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- config/common_bsdapp | 6 -- config/common_linuxapp | 6 -- config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - 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 | 9 --- 9 files changed, 175 deletions(-) delete mode 100644 mk/rte.sharelib.mk diff --git a/config/common_bsdapp b/config/common_bsdapp index 8ff4dc2..7ee5ecf 100644 --- a/config/common_bsdapp +++ b/config/common_bsdapp @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n CONFIG_RTE_BUILD_SHARED_LIB=n # -# Combine to one single library -# -CONFIG_RTE_BUILD_COMBINE_LIBS=n -CONFIG_RTE_LIBNAME=intel_dpdk - -# # Compile Environment Abstraction Layer # CONFIG_RTE_LIBRTE_EAL=y diff --git a/config/common_linuxapp b/config/common_linuxapp index 97f1c9e..ae13805 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n CONFIG_RTE_BUILD_SHARED_LIB=n # -# Combine to one single library -# -CONFIG_RTE_BUILD_COMBINE_LIBS=n -CONFIG_RTE_LIBNAME="intel_dpdk" - -# # Compile Environment Abstraction Layer # CONFIG_RTE_LIBRTE_EAL=y diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8-linuxapp-gcc index d97a885..f1af518 100644 --- a/config/defconfig_ppc_64-power8-linuxapp-gcc +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc @@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y -CONFIG_RTE_LIBNAME="powerpc_dpdk" - # Note: Power doesn't have this support CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n 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 63a41e2..e2baa49 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..7b6f53d 100644 --- a/mk/rte.vars.mk +++ b/mk/rte.vars.mk @@ -67,15 +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:"%"=%) -ifeq ($(RTE_LIBNAME),) -RTE_LIBNAME := intel_dpdk endif # RTE_TARGET is deducted from config when we are building the SDK. -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
[parent not found: <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-13 10:49 ` Kavanagh, Mark B [not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52C87-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2015-03-13 16:07 ` Stephen Hemminger 2015-03-18 12:11 ` Gonzalez Monroy, Sergio 2 siblings, 1 reply; 63+ messages in thread From: Kavanagh, Mark B @ 2015-03-13 10:49 UTC (permalink / raw) To: Gonzalez Monroy, Sergio, dev-VfR2kkLFssw >--- > config/common_bsdapp | 6 -- > config/common_linuxapp | 6 -- > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > 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 | 9 --- > 9 files changed, 175 deletions(-) > delete mode 100644 mk/rte.sharelib.mk > >diff --git a/config/common_bsdapp b/config/common_bsdapp >index 8ff4dc2..7ee5ecf 100644 >--- a/config/common_bsdapp >+++ b/config/common_bsdapp >@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > CONFIG_RTE_BUILD_SHARED_LIB=n > > # >-# Combine to one single library >-# >-CONFIG_RTE_BUILD_COMBINE_LIBS=n >-CONFIG_RTE_LIBNAME=intel_dpdk Hi Sergio, Removing these options breaks compatibility with OVS. While it may be feasible to link to individual static libraries, in our experience, a single combined library provides a much more convenient way of linking. Thanks, Mark >- >-# > # Compile Environment Abstraction Layer > # > CONFIG_RTE_LIBRTE_EAL=y >diff --git a/config/common_linuxapp b/config/common_linuxapp >index 97f1c9e..ae13805 100644 >--- a/config/common_linuxapp >+++ b/config/common_linuxapp >@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > CONFIG_RTE_BUILD_SHARED_LIB=n > > # >-# Combine to one single library >-# >-CONFIG_RTE_BUILD_COMBINE_LIBS=n >-CONFIG_RTE_LIBNAME="intel_dpdk" >- >-# > # Compile Environment Abstraction Layer > # > CONFIG_RTE_LIBRTE_EAL=y >diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8- >linuxapp-gcc >index d97a885..f1af518 100644 >--- a/config/defconfig_ppc_64-power8-linuxapp-gcc >+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc >@@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y > CONFIG_RTE_TOOLCHAIN="gcc" > CONFIG_RTE_TOOLCHAIN_GCC=y > >-CONFIG_RTE_LIBNAME="powerpc_dpdk" >- > # Note: Power doesn't have this support > CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n > >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 63a41e2..e2baa49 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..7b6f53d 100644 >--- a/mk/rte.vars.mk >+++ b/mk/rte.vars.mk >@@ -67,15 +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:"%"=%) >-ifeq ($(RTE_LIBNAME),) >-RTE_LIBNAME := intel_dpdk > endif > > # RTE_TARGET is deducted from config when we are building the SDK. >-- >1.9.3 ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <DC5AD7FA266D86499789B1BCAEC715F846D52C87-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52C87-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-03-13 11:19 ` Gonzalez Monroy, Sergio [not found] ` <5502C7D9.2060503-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-13 11:19 UTC (permalink / raw) To: Kavanagh, Mark B; +Cc: dev-VfR2kkLFssw On 13/03/2015 10:49, Kavanagh, Mark B wrote: >> --- >> config/common_bsdapp | 6 -- >> config/common_linuxapp | 6 -- >> config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >> 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 | 9 --- >> 9 files changed, 175 deletions(-) >> delete mode 100644 mk/rte.sharelib.mk >> >> diff --git a/config/common_bsdapp b/config/common_bsdapp >> index 8ff4dc2..7ee5ecf 100644 >> --- a/config/common_bsdapp >> +++ b/config/common_bsdapp >> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >> CONFIG_RTE_BUILD_SHARED_LIB=n >> >> # >> -# Combine to one single library >> -# >> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >> -CONFIG_RTE_LIBNAME=intel_dpdk > Hi Sergio, > > Removing these options breaks compatibility with OVS. While it may be feasible to link to individual static libraries, in our experience, a single combined library provides a much more convenient way of linking. > > Thanks, > Mark > >> - >> -# >> # Compile Environment Abstraction Layer >> # >> CONFIG_RTE_LIBRTE_EAL=y >> diff --git a/config/common_linuxapp b/config/common_linuxapp >> index 97f1c9e..ae13805 100644 >> --- a/config/common_linuxapp >> +++ b/config/common_linuxapp >> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >> CONFIG_RTE_BUILD_SHARED_LIB=n >> >> # >> -# Combine to one single library >> -# >> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >> -CONFIG_RTE_LIBNAME="intel_dpdk" >> - >> -# >> # Compile Environment Abstraction Layer >> # >> CONFIG_RTE_LIBRTE_EAL=y >> diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8- >> linuxapp-gcc >> index d97a885..f1af518 100644 >> --- a/config/defconfig_ppc_64-power8-linuxapp-gcc >> +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc >> @@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y >> CONFIG_RTE_TOOLCHAIN="gcc" >> CONFIG_RTE_TOOLCHAIN_GCC=y >> >> -CONFIG_RTE_LIBNAME="powerpc_dpdk" >> - >> # Note: Power doesn't have this support >> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n >> >> 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 63a41e2..e2baa49 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..7b6f53d 100644 >> --- a/mk/rte.vars.mk >> +++ b/mk/rte.vars.mk >> @@ -67,15 +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:"%"=%) >> -ifeq ($(RTE_LIBNAME),) >> -RTE_LIBNAME := intel_dpdk >> endif >> >> # RTE_TARGET is deducted from config when we are building the SDK. >> -- >> 1.9.3 Hi Mark, How does this patch break compatibility with OVS? Thanks, Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <5502C7D9.2060503-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <5502C7D9.2060503-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-13 11:34 ` Kavanagh, Mark B [not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52D13-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Kavanagh, Mark B @ 2015-03-13 11:34 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw >On 13/03/2015 10:49, Kavanagh, Mark B wrote: >>> --- >>> config/common_bsdapp | 6 -- >>> config/common_linuxapp | 6 -- >>> config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >>> 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 | 9 --- >>> 9 files changed, 175 deletions(-) >>> delete mode 100644 mk/rte.sharelib.mk >>> >>> diff --git a/config/common_bsdapp b/config/common_bsdapp >>> index 8ff4dc2..7ee5ecf 100644 >>> --- a/config/common_bsdapp >>> +++ b/config/common_bsdapp >>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >>> CONFIG_RTE_BUILD_SHARED_LIB=n >>> >>> # >>> -# Combine to one single library >>> -# >>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >>> -CONFIG_RTE_LIBNAME=intel_dpdk >> Hi Sergio, >> >> Removing these options breaks compatibility with OVS. While it may be feasible to link >to individual static libraries, in our experience, a single combined library provides a >much more convenient way of linking. >> >> Thanks, >> Mark >> >>> - (snip) >>> -endif >>> - >>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) >>> -ifeq ($(RTE_LIBNAME),) >>> -RTE_LIBNAME := intel_dpdk >>> endif >>> >>> # RTE_TARGET is deducted from config when we are building the SDK. >>> -- >>> 1.9.3 >Hi Mark, > >How does this patch break compatibility with OVS? > >Thanks, >Sergio Hey Sergio, We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. Is there a strong technical motivation for removing these options? Thanks, Mark ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <DC5AD7FA266D86499789B1BCAEC715F846D52D13-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52D13-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-03-13 11:48 ` Gonzalez Monroy, Sergio [not found] ` <5502CEAB.8060801-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-13 11:48 UTC (permalink / raw) To: Kavanagh, Mark B; +Cc: dev-VfR2kkLFssw On 13/03/2015 11:34, Kavanagh, Mark B wrote: >> On 13/03/2015 10:49, Kavanagh, Mark B wrote: >>>> --- >>>> config/common_bsdapp | 6 -- >>>> config/common_linuxapp | 6 -- >>>> config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >>>> 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 | 9 --- >>>> 9 files changed, 175 deletions(-) >>>> delete mode 100644 mk/rte.sharelib.mk >>>> >>>> diff --git a/config/common_bsdapp b/config/common_bsdapp >>>> index 8ff4dc2..7ee5ecf 100644 >>>> --- a/config/common_bsdapp >>>> +++ b/config/common_bsdapp >>>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >>>> CONFIG_RTE_BUILD_SHARED_LIB=n >>>> >>>> # >>>> -# Combine to one single library >>>> -# >>>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >>>> -CONFIG_RTE_LIBNAME=intel_dpdk >>> Hi Sergio, >>> >>> Removing these options breaks compatibility with OVS. While it may be feasible to link >> to individual static libraries, in our experience, a single combined library provides a >> much more convenient way of linking. >>> Thanks, >>> Mark >>> >>>> - > > (snip) > > >>>> -endif >>>> - >>>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) >>>> -ifeq ($(RTE_LIBNAME),) >>>> -RTE_LIBNAME := intel_dpdk >>>> endif >>>> >>>> # RTE_TARGET is deducted from config when we are building the SDK. >>>> -- >>>> 1.9.3 >> Hi Mark, >> >> How does this patch break compatibility with OVS? >> >> Thanks, >> Sergio > Hey Sergio, > > We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. > > Is there a strong technical motivation for removing these options? > > Thanks, > Mark From a shared library point of view, it just does not make sense to have applications linked against a 'combined' library that may have different features built in it. Removing these options, aside from the obvious 'less build config option', it simplifies maintenance of makefiles as we currently have a separated makefile with specific rules just for combined library. It is pretty straight forward to build a single combined archive out of multiple archives, would it be acceptable to have a script to do this? Thanks, Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <5502CEAB.8060801-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <5502CEAB.8060801-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-13 13:16 ` Kavanagh, Mark B [not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52DDA-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2015-03-13 13:17 ` Neil Horman 1 sibling, 1 reply; 63+ messages in thread From: Kavanagh, Mark B @ 2015-03-13 13:16 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw >-----Original Message----- >From: Gonzalez Monroy, Sergio >Sent: Friday, March 13, 2015 11:49 AM >To: Kavanagh, Mark B >Cc: dev@dpdk.org >Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options > >On 13/03/2015 11:34, Kavanagh, Mark B wrote: >>> On 13/03/2015 10:49, Kavanagh, Mark B wrote: >>>>> --- >>>>> config/common_bsdapp | 6 -- >>>>> config/common_linuxapp | 6 -- >>>>> config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >>>>> 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 | 9 --- >>>>> 9 files changed, 175 deletions(-) >>>>> delete mode 100644 mk/rte.sharelib.mk >>>>> >>>>> diff --git a/config/common_bsdapp b/config/common_bsdapp >>>>> index 8ff4dc2..7ee5ecf 100644 >>>>> --- a/config/common_bsdapp >>>>> +++ b/config/common_bsdapp >>>>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >>>>> CONFIG_RTE_BUILD_SHARED_LIB=n >>>>> >>>>> # >>>>> -# Combine to one single library >>>>> -# >>>>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >>>>> -CONFIG_RTE_LIBNAME=intel_dpdk >>>> Hi Sergio, >>>> >>>> Removing these options breaks compatibility with OVS. While it may be feasible to link >>> to individual static libraries, in our experience, a single combined library provides a >>> much more convenient way of linking. >>>> Thanks, >>>> Mark >>>> >>>>> - >> >> (snip) >> >> >>>>> -endif >>>>> - >>>>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) >>>>> -ifeq ($(RTE_LIBNAME),) >>>>> -RTE_LIBNAME := intel_dpdk >>>>> endif >>>>> >>>>> # RTE_TARGET is deducted from config when we are building the SDK. >>>>> -- >>>>> 1.9.3 >>> Hi Mark, >>> >>> How does this patch break compatibility with OVS? >>> >>> Thanks, >>> Sergio >> Hey Sergio, >> >> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single >static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the >combined library option breaks compatibility with any application that links against the >combined DPDK library. >> >> Is there a strong technical motivation for removing these options? >> >> Thanks, >> Mark > From a shared library point of view, it just does not make sense to >have applications linked against a 'combined' library that may have >different features built in it. > For OVS, we don't build DPDK as a set of shared libraries, but rather an individual static library, due to the performance penalties inherent in using shared libraries. >Removing these options, aside from the obvious 'less build config >option', it simplifies maintenance of makefiles as we currently have a >separated makefile with specific rules just for combined library. > >It is pretty straight forward to build a single combined archive out of >multiple archives, would it be acceptable to have a script to do this? > This seems a bit 'hacky' to me and I'm not sure that it would be amenable to the OVS maintainers. Unless I'm overlooking something here, I'd prefer to maintain the status quo. >Thanks, >Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <DC5AD7FA266D86499789B1BCAEC715F846D52DDA-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52DDA-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2015-03-13 14:11 ` Gonzalez Monroy, Sergio 0 siblings, 0 replies; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-13 14:11 UTC (permalink / raw) To: Kavanagh, Mark B; +Cc: dev-VfR2kkLFssw On 13/03/2015 13:16, Kavanagh, Mark B wrote: > >> -----Original Message----- >> From: Gonzalez Monroy, Sergio >> Sent: Friday, March 13, 2015 11:49 AM >> To: Kavanagh, Mark B >> Cc: dev-VfR2kkLFssw@public.gmane.org >> Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options >> >> On 13/03/2015 11:34, Kavanagh, Mark B wrote: >>>> On 13/03/2015 10:49, Kavanagh, Mark B wrote: >>>>>> --- >>>>>> config/common_bsdapp | 6 -- >>>>>> config/common_linuxapp | 6 -- >>>>>> config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >>>>>> 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 | 9 --- >>>>>> 9 files changed, 175 deletions(-) >>>>>> delete mode 100644 mk/rte.sharelib.mk >>>>>> >>>>>> diff --git a/config/common_bsdapp b/config/common_bsdapp >>>>>> index 8ff4dc2..7ee5ecf 100644 >>>>>> --- a/config/common_bsdapp >>>>>> +++ b/config/common_bsdapp >>>>>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >>>>>> CONFIG_RTE_BUILD_SHARED_LIB=n >>>>>> >>>>>> # >>>>>> -# Combine to one single library >>>>>> -# >>>>>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >>>>>> -CONFIG_RTE_LIBNAME=intel_dpdk >>>>> Hi Sergio, >>>>> >>>>> Removing these options breaks compatibility with OVS. While it may be feasible to link >>>> to individual static libraries, in our experience, a single combined library provides a >>>> much more convenient way of linking. >>>>> Thanks, >>>>> Mark >>>>> >>>>>> - >>> (snip) >>> >>> >>>>>> -endif >>>>>> - >>>>>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) >>>>>> -ifeq ($(RTE_LIBNAME),) >>>>>> -RTE_LIBNAME := intel_dpdk >>>>>> endif >>>>>> >>>>>> # RTE_TARGET is deducted from config when we are building the SDK. >>>>>> -- >>>>>> 1.9.3 >>>> Hi Mark, >>>> >>>> How does this patch break compatibility with OVS? >>>> >>>> Thanks, >>>> Sergio >>> Hey Sergio, >>> >>> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single >> static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the >> combined library option breaks compatibility with any application that links against the >> combined DPDK library. >>> Is there a strong technical motivation for removing these options? >>> >>> Thanks, >>> Mark >> From a shared library point of view, it just does not make sense to >> have applications linked against a 'combined' library that may have >> different features built in it. >> > For OVS, we don't build DPDK as a set of shared libraries, but rather an individual static library, due to the performance penalties inherent in using shared libraries. > >> Removing these options, aside from the obvious 'less build config >> option', it simplifies maintenance of makefiles as we currently have a >> separated makefile with specific rules just for combined library. >> >> It is pretty straight forward to build a single combined archive out of >> multiple archives, would it be acceptable to have a script to do this? >> > This seems a bit 'hacky' to me and I'm not sure that it would be amenable to the OVS maintainers. Unless I'm overlooking something here, I'd prefer to maintain the status quo. This may be a case of personal opinions, but I don't think there is anything 'hacky' about it. Straight forward extract objects from archive, then archive them into a single library. Currently to create a combined library we just copy all objects into one directory, then create the combined archive. After the patch, the script just needs to extract all objects from individual libraries into a directory and archive them all. In my opinion, one little exra step, same result plus we get less build config options, simplify lib building by removing the 'combined' lib path. >> Thanks, >> Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <5502CEAB.8060801-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-13 13:16 ` Kavanagh, Mark B @ 2015-03-13 13:17 ` Neil Horman [not found] ` <20150313131719.GA28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 1 sibling, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-03-13 13:17 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Fri, Mar 13, 2015 at 11:48:59AM +0000, Gonzalez Monroy, Sergio wrote: > On 13/03/2015 11:34, Kavanagh, Mark B wrote: > >>On 13/03/2015 10:49, Kavanagh, Mark B wrote: > >>>>--- > >>>>config/common_bsdapp | 6 -- > >>>>config/common_linuxapp | 6 -- > >>>>config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > >>>>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 | 9 --- > >>>>9 files changed, 175 deletions(-) > >>>>delete mode 100644 mk/rte.sharelib.mk > >>>> > >>>>diff --git a/config/common_bsdapp b/config/common_bsdapp > >>>>index 8ff4dc2..7ee5ecf 100644 > >>>>--- a/config/common_bsdapp > >>>>+++ b/config/common_bsdapp > >>>>@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > >>>>CONFIG_RTE_BUILD_SHARED_LIB=n > >>>> > >>>># > >>>>-# Combine to one single library > >>>>-# > >>>>-CONFIG_RTE_BUILD_COMBINE_LIBS=n > >>>>-CONFIG_RTE_LIBNAME=intel_dpdk > >>>Hi Sergio, > >>> > >>>Removing these options breaks compatibility with OVS. While it may be feasible to link > >>to individual static libraries, in our experience, a single combined library provides a > >>much more convenient way of linking. > >>>Thanks, > >>>Mark > >>> > >>>>- > > > >(snip) > > > > > >>>>-endif > >>>>- > >>>>-RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) > >>>>-ifeq ($(RTE_LIBNAME),) > >>>>-RTE_LIBNAME := intel_dpdk > >>>>endif > >>>> > >>>># RTE_TARGET is deducted from config when we are building the SDK. > >>>>-- > >>>>1.9.3 > >>Hi Mark, > >> > >>How does this patch break compatibility with OVS? > >> > >>Thanks, > >>Sergio > >Hey Sergio, > > > >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. > > > >Is there a strong technical motivation for removing these options? > > > >Thanks, > >Mark > From a shared library point of view, it just does not make sense to have > applications linked against a 'combined' library that may have different > features built in it. > > Removing these options, aside from the obvious 'less build config option', > it simplifies maintenance of makefiles as we currently have a separated > makefile with specific rules just for combined library. > > It is pretty straight forward to build a single combined archive out of > multiple archives, would it be acceptable to have a script to do this? > > Thanks, > Sergio > +1 For the static case, its easy to do a post build combination of archives. For the shared library case, its equally easy to simply create a linker scripts call <CONFIG_RTE_LIBNAME>.so that pulls in all the individual libraries. Neil ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150313131719.GA28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <20150313131719.GA28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-03-13 14:12 ` Stefan Puiu [not found] ` <CACKs7VAOZ-e6=jC_kUJC0eO5wfj5r3uaPOR3QGyHpzxC_vLttA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Stefan Puiu @ 2015-03-13 14:12 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw Hi, 2 cents from a DPDK library user - I make 2 changes to the default linux+gcc configuration: combine libraries and build shared libraries (since I want 2 instances of the app, it didn't make sense to me to link statically). I tried working with the individual libs, but adding all of them with --start-group/-end-group just seemed so much more painful than simply linking against one lib. I know there are some Makefile variables to help with this, but I use scons for building my app, so that doesn't help much. Of course, if that can be achieved easily after building all the libraries, that's fine. But I think combining the libs makes a lot of sense in many cases. Thanks, Stefan. On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote: > On Fri, Mar 13, 2015 at 11:48:59AM +0000, Gonzalez Monroy, Sergio wrote: >> On 13/03/2015 11:34, Kavanagh, Mark B wrote: >> >>On 13/03/2015 10:49, Kavanagh, Mark B wrote: >> >>>>--- >> >>>>config/common_bsdapp | 6 -- >> >>>>config/common_linuxapp | 6 -- >> >>>>config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >> >>>>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 | 9 --- >> >>>>9 files changed, 175 deletions(-) >> >>>>delete mode 100644 mk/rte.sharelib.mk >> >>>> >> >>>>diff --git a/config/common_bsdapp b/config/common_bsdapp >> >>>>index 8ff4dc2..7ee5ecf 100644 >> >>>>--- a/config/common_bsdapp >> >>>>+++ b/config/common_bsdapp >> >>>>@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >> >>>>CONFIG_RTE_BUILD_SHARED_LIB=n >> >>>> >> >>>># >> >>>>-# Combine to one single library >> >>>>-# >> >>>>-CONFIG_RTE_BUILD_COMBINE_LIBS=n >> >>>>-CONFIG_RTE_LIBNAME=intel_dpdk >> >>>Hi Sergio, >> >>> >> >>>Removing these options breaks compatibility with OVS. While it may be feasible to link >> >>to individual static libraries, in our experience, a single combined library provides a >> >>much more convenient way of linking. >> >>>Thanks, >> >>>Mark >> >>> >> >>>>- >> > >> >(snip) >> > >> > >> >>>>-endif >> >>>>- >> >>>>-RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) >> >>>>-ifeq ($(RTE_LIBNAME),) >> >>>>-RTE_LIBNAME := intel_dpdk >> >>>>endif >> >>>> >> >>>># RTE_TARGET is deducted from config when we are building the SDK. >> >>>>-- >> >>>>1.9.3 >> >>Hi Mark, >> >> >> >>How does this patch break compatibility with OVS? >> >> >> >>Thanks, >> >>Sergio >> >Hey Sergio, >> > >> >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. >> > >> >Is there a strong technical motivation for removing these options? >> > >> >Thanks, >> >Mark >> From a shared library point of view, it just does not make sense to have >> applications linked against a 'combined' library that may have different >> features built in it. >> >> Removing these options, aside from the obvious 'less build config option', >> it simplifies maintenance of makefiles as we currently have a separated >> makefile with specific rules just for combined library. >> >> It is pretty straight forward to build a single combined archive out of >> multiple archives, would it be acceptable to have a script to do this? >> >> Thanks, >> Sergio >> > +1 > > For the static case, its easy to do a post build combination of archives. For > the shared library case, its equally easy to simply create a linker scripts call > <CONFIG_RTE_LIBNAME>.so that pulls in all the individual libraries. > > Neil > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <CACKs7VAOZ-e6=jC_kUJC0eO5wfj5r3uaPOR3QGyHpzxC_vLttA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <CACKs7VAOZ-e6=jC_kUJC0eO5wfj5r3uaPOR3QGyHpzxC_vLttA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-03-13 15:18 ` Neil Horman [not found] ` <20150313151855.GG28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Neil Horman @ 2015-03-13 15:18 UTC (permalink / raw) To: Stefan Puiu; +Cc: dev-VfR2kkLFssw On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote: > Hi, > > 2 cents from a DPDK library user - I make 2 changes to the default > linux+gcc configuration: combine libraries and build shared libraries > (since I want 2 instances of the app, it didn't make sense to me to > link statically). I tried working with the individual libs, but adding > all of them with --start-group/-end-group just seemed so much more > painful than simply linking against one lib. I know there are some > Makefile variables to help with this, but I use scons for building my > app, so that doesn't help much. > > Of course, if that can be achieved easily after building all the > libraries, that's fine. But I think combining the libs makes a lot of > sense in many cases. > So do it, create a linker script that internally contains one line: INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc) Name the file libdpdk.so then when you build your app, just link -ldpdk Done. Neil > Thanks, > Stefan. > > On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote: > > On Fri, Mar 13, 2015 at 11:48:59AM +0000, Gonzalez Monroy, Sergio wrote: > >> On 13/03/2015 11:34, Kavanagh, Mark B wrote: > >> >>On 13/03/2015 10:49, Kavanagh, Mark B wrote: > >> >>>>--- > >> >>>>config/common_bsdapp | 6 -- > >> >>>>config/common_linuxapp | 6 -- > >> >>>>config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > >> >>>>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 | 9 --- > >> >>>>9 files changed, 175 deletions(-) > >> >>>>delete mode 100644 mk/rte.sharelib.mk > >> >>>> > >> >>>>diff --git a/config/common_bsdapp b/config/common_bsdapp > >> >>>>index 8ff4dc2..7ee5ecf 100644 > >> >>>>--- a/config/common_bsdapp > >> >>>>+++ b/config/common_bsdapp > >> >>>>@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > >> >>>>CONFIG_RTE_BUILD_SHARED_LIB=n > >> >>>> > >> >>>># > >> >>>>-# Combine to one single library > >> >>>>-# > >> >>>>-CONFIG_RTE_BUILD_COMBINE_LIBS=n > >> >>>>-CONFIG_RTE_LIBNAME=intel_dpdk > >> >>>Hi Sergio, > >> >>> > >> >>>Removing these options breaks compatibility with OVS. While it may be feasible to link > >> >>to individual static libraries, in our experience, a single combined library provides a > >> >>much more convenient way of linking. > >> >>>Thanks, > >> >>>Mark > >> >>> > >> >>>>- > >> > > >> >(snip) > >> > > >> > > >> >>>>-endif > >> >>>>- > >> >>>>-RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) > >> >>>>-ifeq ($(RTE_LIBNAME),) > >> >>>>-RTE_LIBNAME := intel_dpdk > >> >>>>endif > >> >>>> > >> >>>># RTE_TARGET is deducted from config when we are building the SDK. > >> >>>>-- > >> >>>>1.9.3 > >> >>Hi Mark, > >> >> > >> >>How does this patch break compatibility with OVS? > >> >> > >> >>Thanks, > >> >>Sergio > >> >Hey Sergio, > >> > > >> >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. > >> > > >> >Is there a strong technical motivation for removing these options? > >> > > >> >Thanks, > >> >Mark > >> From a shared library point of view, it just does not make sense to have > >> applications linked against a 'combined' library that may have different > >> features built in it. > >> > >> Removing these options, aside from the obvious 'less build config option', > >> it simplifies maintenance of makefiles as we currently have a separated > >> makefile with specific rules just for combined library. > >> > >> It is pretty straight forward to build a single combined archive out of > >> multiple archives, would it be acceptable to have a script to do this? > >> > >> Thanks, > >> Sergio > >> > > +1 > > > > For the static case, its easy to do a post build combination of archives. For > > the shared library case, its equally easy to simply create a linker scripts call > > <CONFIG_RTE_LIBNAME>.so that pulls in all the individual libraries. > > > > Neil > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <20150313151855.GG28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <20150313151855.GG28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> @ 2015-03-13 15:28 ` Gonzalez Monroy, Sergio [not found] ` <55030200.4070505-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-13 15:28 UTC (permalink / raw) To: Neil Horman; +Cc: dev-VfR2kkLFssw On 13/03/2015 15:18, Neil Horman wrote: > On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote: >> Hi, >> >> 2 cents from a DPDK library user - I make 2 changes to the default >> linux+gcc configuration: combine libraries and build shared libraries >> (since I want 2 instances of the app, it didn't make sense to me to >> link statically). I tried working with the individual libs, but adding >> all of them with --start-group/-end-group just seemed so much more >> painful than simply linking against one lib. I know there are some >> Makefile variables to help with this, but I use scons for building my >> app, so that doesn't help much. >> >> Of course, if that can be achieved easily after building all the >> libraries, that's fine. But I think combining the libs makes a lot of >> sense in many cases. >> > So do it, create a linker script that internally contains one line: > INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc) > > Name the file libdpdk.so > > then when you build your app, just link -ldpdk > > Done. > > Neil Plus I believe that as it currently stands, building combined shared libraries will be broken the moment we have different versions of any API because the linking for the combined lib does not use a version map. Sergio >> Thanks, >> Stefan. >> >> On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote: >>> On Fri, Mar 13, 2015 at 11:48:59AM +0000, Gonzalez Monroy, Sergio wrote: >>>> On 13/03/2015 11:34, Kavanagh, Mark B wrote: >>>>>> On 13/03/2015 10:49, Kavanagh, Mark B wrote: >>>>>>>> --- >>>>>>>> config/common_bsdapp | 6 -- >>>>>>>> config/common_linuxapp | 6 -- >>>>>>>> config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - >>>>>>>> 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 | 9 --- >>>>>>>> 9 files changed, 175 deletions(-) >>>>>>>> delete mode 100644 mk/rte.sharelib.mk >>>>>>>> >>>>>>>> diff --git a/config/common_bsdapp b/config/common_bsdapp >>>>>>>> index 8ff4dc2..7ee5ecf 100644 >>>>>>>> --- a/config/common_bsdapp >>>>>>>> +++ b/config/common_bsdapp >>>>>>>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n >>>>>>>> CONFIG_RTE_BUILD_SHARED_LIB=n >>>>>>>> >>>>>>>> # >>>>>>>> -# Combine to one single library >>>>>>>> -# >>>>>>>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n >>>>>>>> -CONFIG_RTE_LIBNAME=intel_dpdk >>>>>>> Hi Sergio, >>>>>>> >>>>>>> Removing these options breaks compatibility with OVS. While it may be feasible to link >>>>>> to individual static libraries, in our experience, a single combined library provides a >>>>>> much more convenient way of linking. >>>>>>> Thanks, >>>>>>> Mark >>>>>>> >>>>>>>> - >>>>> (snip) >>>>> >>>>> >>>>>>>> -endif >>>>>>>> - >>>>>>>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) >>>>>>>> -ifeq ($(RTE_LIBNAME),) >>>>>>>> -RTE_LIBNAME := intel_dpdk >>>>>>>> endif >>>>>>>> >>>>>>>> # RTE_TARGET is deducted from config when we are building the SDK. >>>>>>>> -- >>>>>>>> 1.9.3 >>>>>> Hi Mark, >>>>>> >>>>>> How does this patch break compatibility with OVS? >>>>>> >>>>>> Thanks, >>>>>> Sergio >>>>> Hey Sergio, >>>>> >>>>> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. >>>>> >>>>> Is there a strong technical motivation for removing these options? >>>>> >>>>> Thanks, >>>>> Mark >>>> From a shared library point of view, it just does not make sense to have >>>> applications linked against a 'combined' library that may have different >>>> features built in it. >>>> >>>> Removing these options, aside from the obvious 'less build config option', >>>> it simplifies maintenance of makefiles as we currently have a separated >>>> makefile with specific rules just for combined library. >>>> >>>> It is pretty straight forward to build a single combined archive out of >>>> multiple archives, would it be acceptable to have a script to do this? >>>> >>>> Thanks, >>>> Sergio >>>> >>> +1 >>> >>> For the static case, its easy to do a post build combination of archives. For >>> the shared library case, its equally easy to simply create a linker scripts call >>> <CONFIG_RTE_LIBNAME>.so that pulls in all the individual libraries. >>> >>> Neil >>> ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <55030200.4070505-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <55030200.4070505-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-13 16:16 ` Neil Horman 0 siblings, 0 replies; 63+ messages in thread From: Neil Horman @ 2015-03-13 16:16 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Fri, Mar 13, 2015 at 03:28:00PM +0000, Gonzalez Monroy, Sergio wrote: > On 13/03/2015 15:18, Neil Horman wrote: > >On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote: > >>Hi, > >> > >>2 cents from a DPDK library user - I make 2 changes to the default > >>linux+gcc configuration: combine libraries and build shared libraries > >>(since I want 2 instances of the app, it didn't make sense to me to > >>link statically). I tried working with the individual libs, but adding > >>all of them with --start-group/-end-group just seemed so much more > >>painful than simply linking against one lib. I know there are some > >>Makefile variables to help with this, but I use scons for building my > >>app, so that doesn't help much. > >> > >>Of course, if that can be achieved easily after building all the > >>libraries, that's fine. But I think combining the libs makes a lot of > >>sense in many cases. > >> > >So do it, create a linker script that internally contains one line: > >INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc) > > > >Name the file libdpdk.so > > > >then when you build your app, just link -ldpdk > > > >Done. > > > >Neil > > Plus I believe that as it currently stands, building combined shared > libraries will be broken > the moment we have different versions of any API because the linking for the > combined lib > does not use a version map. > Correct, the above is the only way to create a single library that is properly versioned, short of _only_ building a single library and exporting the version map for that (which is non-sensical, as it defeats the purpose of DSO's). > Sergio > >>Thanks, > >>Stefan. > >> > >>On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote: > >>>On Fri, Mar 13, 2015 at 11:48:59AM +0000, Gonzalez Monroy, Sergio wrote: > >>>>On 13/03/2015 11:34, Kavanagh, Mark B wrote: > >>>>>>On 13/03/2015 10:49, Kavanagh, Mark B wrote: > >>>>>>>>--- > >>>>>>>>config/common_bsdapp | 6 -- > >>>>>>>>config/common_linuxapp | 6 -- > >>>>>>>>config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > >>>>>>>>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 | 9 --- > >>>>>>>>9 files changed, 175 deletions(-) > >>>>>>>>delete mode 100644 mk/rte.sharelib.mk > >>>>>>>> > >>>>>>>>diff --git a/config/common_bsdapp b/config/common_bsdapp > >>>>>>>>index 8ff4dc2..7ee5ecf 100644 > >>>>>>>>--- a/config/common_bsdapp > >>>>>>>>+++ b/config/common_bsdapp > >>>>>>>>@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > >>>>>>>>CONFIG_RTE_BUILD_SHARED_LIB=n > >>>>>>>> > >>>>>>>># > >>>>>>>>-# Combine to one single library > >>>>>>>>-# > >>>>>>>>-CONFIG_RTE_BUILD_COMBINE_LIBS=n > >>>>>>>>-CONFIG_RTE_LIBNAME=intel_dpdk > >>>>>>>Hi Sergio, > >>>>>>> > >>>>>>>Removing these options breaks compatibility with OVS. While it may be feasible to link > >>>>>>to individual static libraries, in our experience, a single combined library provides a > >>>>>>much more convenient way of linking. > >>>>>>>Thanks, > >>>>>>>Mark > >>>>>>> > >>>>>>>>- > >>>>>(snip) > >>>>> > >>>>> > >>>>>>>>-endif > >>>>>>>>- > >>>>>>>>-RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) > >>>>>>>>-ifeq ($(RTE_LIBNAME),) > >>>>>>>>-RTE_LIBNAME := intel_dpdk > >>>>>>>>endif > >>>>>>>> > >>>>>>>># RTE_TARGET is deducted from config when we are building the SDK. > >>>>>>>>-- > >>>>>>>>1.9.3 > >>>>>>Hi Mark, > >>>>>> > >>>>>>How does this patch break compatibility with OVS? > >>>>>> > >>>>>>Thanks, > >>>>>>Sergio > >>>>>Hey Sergio, > >>>>> > >>>>>We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library. > >>>>> > >>>>>Is there a strong technical motivation for removing these options? > >>>>> > >>>>>Thanks, > >>>>>Mark > >>>> From a shared library point of view, it just does not make sense to have > >>>>applications linked against a 'combined' library that may have different > >>>>features built in it. > >>>> > >>>>Removing these options, aside from the obvious 'less build config option', > >>>>it simplifies maintenance of makefiles as we currently have a separated > >>>>makefile with specific rules just for combined library. > >>>> > >>>>It is pretty straight forward to build a single combined archive out of > >>>>multiple archives, would it be acceptable to have a script to do this? > >>>> > >>>>Thanks, > >>>>Sergio > >>>> > >>>+1 > >>> > >>>For the static case, its easy to do a post build combination of archives. For > >>>the shared library case, its equally easy to simply create a linker scripts call > >>><CONFIG_RTE_LIBNAME>.so that pulls in all the individual libraries. > >>> > >>>Neil > >>> > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-13 10:49 ` Kavanagh, Mark B @ 2015-03-13 16:07 ` Stephen Hemminger 2015-03-13 16:32 ` Neil Horman 2015-03-13 16:38 ` Gonzalez Monroy, Sergio 2015-03-18 12:11 ` Gonzalez Monroy, Sergio 2 siblings, 2 replies; 63+ messages in thread From: Stephen Hemminger @ 2015-03-13 16:07 UTC (permalink / raw) To: Sergio Gonzalez Monroy; +Cc: dev-VfR2kkLFssw On Thu, 12 Mar 2015 16:27:58 +0000 Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: > Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. > > Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > --- NAK. The combined library is good and useful for those who want simplicity and build with static library. It is not clear what you are trying to solve. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options 2015-03-13 16:07 ` Stephen Hemminger @ 2015-03-13 16:32 ` Neil Horman 2015-03-13 16:38 ` Gonzalez Monroy, Sergio 1 sibling, 0 replies; 63+ messages in thread From: Neil Horman @ 2015-03-13 16:32 UTC (permalink / raw) To: Stephen Hemminger; +Cc: dev-VfR2kkLFssw On Fri, Mar 13, 2015 at 09:07:59AM -0700, Stephen Hemminger wrote: > On Thu, 12 Mar 2015 16:27:58 +0000 > Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: > > > Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. > > > > Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > > --- > > NAK. The combined library is good and useful for those who want simplicity > and build with static library. > No one is removing the ability to link against a single library, its simple to do by hand. The only thing this does is the codification of doing so as part of the DPDK link process. > It is not clear what you are trying to solve. > In my mind, the problem is that using combined libs breaks the versioning infrastrucure. Because .o files can only be linked into .so files once, the combined lib in the dpdk tree links all .o files at the same time. But because version maps are specified per individual library, and we can only specify one at link time, we are left with a decision as to how to bring both together: 1) We can write a script to merge all the versioning files into one, and apply that to the master link 2) Drop the combined libraries all together, and use a linker script to simulate the merging of the libraries Option two seems a bit rickety, and prone to failure, whereas option two seems both easy and clean (at least in my view). Just create a file libdpdk.so, that is actually a text file with the contents: INPUT(-lrte_malloc -lrte_mempool ....etc) That will allow you to link applications to a single library -ldpdk, and things will just work. The only additional requriement that puts on your head is that the individual libraries need to be installed locally on the target system, but thats a run time requirement, not build time, and is easily managed with whatever run time software management tools you care to use Neil ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options 2015-03-13 16:07 ` Stephen Hemminger 2015-03-13 16:32 ` Neil Horman @ 2015-03-13 16:38 ` Gonzalez Monroy, Sergio 1 sibling, 0 replies; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-13 16:38 UTC (permalink / raw) To: Stephen Hemminger; +Cc: dev-VfR2kkLFssw On 13/03/2015 16:07, Stephen Hemminger wrote: > On Thu, 12 Mar 2015 16:27:58 +0000 > Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: > >> Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. >> >> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> >> --- > NAK. The combined library is good and useful for those who want simplicity > and build with static library. > > It is not clear what you are trying to solve. As I mentioned in other post, you can merge multiple archives into a single/combined one pretty easily. I think we can agree that it is not useful for shared libraries, and with versioning in place, combined shared library will be broken the moment we version an API. I don't think we need build config options just for the combined static library when we can achieve the same result with a simple script post build. Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-13 10:49 ` Kavanagh, Mark B 2015-03-13 16:07 ` Stephen Hemminger @ 2015-03-18 12:11 ` Gonzalez Monroy, Sergio [not found] ` <55096B86.7040303-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2 siblings, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-18 12:11 UTC (permalink / raw) To: dev-VfR2kkLFssw On 12/03/2015 16:27, Sergio Gonzalez Monroy wrote: > Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. > > Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > --- > config/common_bsdapp | 6 -- > config/common_linuxapp | 6 -- > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > 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 | 9 --- > 9 files changed, 175 deletions(-) > delete mode 100644 mk/rte.sharelib.mk > > diff --git a/config/common_bsdapp b/config/common_bsdapp > index 8ff4dc2..7ee5ecf 100644 > --- a/config/common_bsdapp > +++ b/config/common_bsdapp > @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > CONFIG_RTE_BUILD_SHARED_LIB=n > > # > -# Combine to one single library > -# > -CONFIG_RTE_BUILD_COMBINE_LIBS=n > -CONFIG_RTE_LIBNAME=intel_dpdk > - > -# > # Compile Environment Abstraction Layer > # > CONFIG_RTE_LIBRTE_EAL=y > diff --git a/config/common_linuxapp b/config/common_linuxapp > index 97f1c9e..ae13805 100644 > --- a/config/common_linuxapp > +++ b/config/common_linuxapp > @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > CONFIG_RTE_BUILD_SHARED_LIB=n > > # > -# Combine to one single library > -# > -CONFIG_RTE_BUILD_COMBINE_LIBS=n > -CONFIG_RTE_LIBNAME="intel_dpdk" > - > -# > # Compile Environment Abstraction Layer > # > CONFIG_RTE_LIBRTE_EAL=y > diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8-linuxapp-gcc > index d97a885..f1af518 100644 > --- a/config/defconfig_ppc_64-power8-linuxapp-gcc > +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc > @@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y > CONFIG_RTE_TOOLCHAIN="gcc" > CONFIG_RTE_TOOLCHAIN_GCC=y > > -CONFIG_RTE_LIBNAME="powerpc_dpdk" > - > # Note: Power doesn't have this support > CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n > > 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 63a41e2..e2baa49 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..7b6f53d 100644 > --- a/mk/rte.vars.mk > +++ b/mk/rte.vars.mk > @@ -67,15 +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:"%"=%) > -ifeq ($(RTE_LIBNAME),) > -RTE_LIBNAME := intel_dpdk > endif > > # RTE_TARGET is deducted from config when we are building the SDK. Given that the patch to remove combined libraries is not welcome, I'll try to explain the current situation so we can agree on the way forward. Currently we have build config option for shared libraries and combined libraries. Thus, this results in four possible combinations when building dpdk: - not combined static - not combined shared - combined static - combined shared The makefile rules/targets for combined are different than for not combined. Thus, we currently have two different files for archive/linking (rte.lib.mk and rte.sharelib.mk). Since having versioning, combined shared libraries build will be broken the moment we add a versioned API, as we do not have a global version map that we use when linking such library. Also in my opinion, we would want to prevent users linking against a combined libdpdk.so that may have different features built-in, with the corresponding debugging difficulties when users report different problems/errors. I think this would defeat many of the advantages of using shared libraries. By removing the combined library build option, we would simplify the build system with only two possible choices: - static - shared This would allow us to remove one file (rte.sharelib.mk) and have a single file with archive/linking rules. For the convenience of linking against a single library instead of the multiple dpdk libraries, there are a few ways to go around it: - for combined static lib, we can either have a script to re-archive all libraries into a single/combined library (ie. extract all archives into one directory, the re-archive all objects into a combined library), or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). - for combined shared lib, we can use a linker script (ie. INPUT ( -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a global version map (either somehow merging all independent version maps or maintaining a global version map). My preference would be to remove the combined libs as a build config option, then either add scripts to create those linker scripts or document it so users know how to create their own linker scripts. This would simplify the build process and still be able to provide the convenience of the combined library by using a linker script. Comments? Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <55096B86.7040303-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <55096B86.7040303-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-18 12:59 ` Thomas Monjalon 2015-03-18 15:30 ` Stefan Puiu 2015-03-26 8:52 ` Gonzalez Monroy, Sergio 2015-03-18 16:41 ` Neil Horman 1 sibling, 2 replies; 63+ messages in thread From: Thomas Monjalon @ 2015-03-18 12:59 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw Hi Sergio, Thank you for explaining the situation. 2015-03-18 12:11, Gonzalez Monroy, Sergio: > Given that the patch to remove combined libraries is not welcome, I'll > try to explain the current situation so we can agree on the way forward. > > Currently we have build config option for shared libraries and combined > libraries. Thus, this results in four possible combinations when > building dpdk: > - not combined static > - not combined shared > - combined static > - combined shared > > The makefile rules/targets for combined are different than for not > combined. Thus, we currently have two different files for > archive/linking (rte.lib.mk and rte.sharelib.mk). > > Since having versioning, combined shared libraries build will be broken > the moment we add a versioned API, as we do not have a global version > map that we use when linking such library. > Also in my opinion, we would want to prevent users linking against a > combined libdpdk.so that may have different features built-in, with the > corresponding debugging difficulties when users > report different problems/errors. I think this would defeat many of the > advantages of using shared libraries. > > By removing the combined library build option, we would simplify the > build system with only two possible choices: > - static > - shared +1 I believe that simplification is the way go. > This would allow us to remove one file (rte.sharelib.mk) and have a > single file with archive/linking rules. > > For the convenience of linking against a single library instead of the > multiple dpdk libraries, there are a few ways to go around it: > - for combined static lib, we can either have a script to re-archive > all libraries into a single/combined library (ie. extract all archives > into one directory, the re-archive all objects into a combined library), > or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). > - for combined shared lib, we can use a linker script (ie. INPUT ( > -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a > global version map (either somehow merging all independent version maps > or maintaining a global version map). > > My preference would be to remove the combined libs as a build config > option, then either add scripts to create those linker scripts or > document it so users know how to create their own linker scripts. > This would simplify the build process and still be able to provide the > convenience of the combined library by using a linker script. > > Comments? You're right about the word convenience. There are many ways to provide such convenience. The first one is to simply use the DPDK makefiles which abstract linking problems. If using DPDK framework is not an option, we can add new conveniences like scripts or pkgconfig support. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options 2015-03-18 12:59 ` Thomas Monjalon @ 2015-03-18 15:30 ` Stefan Puiu [not found] ` <CACKs7VBNmmdPoBcv-vPpn-HVQr2Nd2Gr_2shTuqdh2L1MsfY_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-03-26 8:52 ` Gonzalez Monroy, Sergio 1 sibling, 1 reply; 63+ messages in thread From: Stefan Puiu @ 2015-03-18 15:30 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev-VfR2kkLFssw Hi, On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote: > Hi Sergio, > > Thank you for explaining the situation. > > 2015-03-18 12:11, Gonzalez Monroy, Sergio: >> Given that the patch to remove combined libraries is not welcome, I'll >> try to explain the current situation so we can agree on the way forward. >> >> Currently we have build config option for shared libraries and combined >> libraries. Thus, this results in four possible combinations when >> building dpdk: >> - not combined static >> - not combined shared >> - combined static >> - combined shared >> >> The makefile rules/targets for combined are different than for not >> combined. Thus, we currently have two different files for >> archive/linking (rte.lib.mk and rte.sharelib.mk). >> >> Since having versioning, combined shared libraries build will be broken >> the moment we add a versioned API, as we do not have a global version >> map that we use when linking such library. >> Also in my opinion, we would want to prevent users linking against a >> combined libdpdk.so that may have different features built-in, with the >> corresponding debugging difficulties when users >> report different problems/errors. I think this would defeat many of the >> advantages of using shared libraries. >> >> By removing the combined library build option, we would simplify the >> build system with only two possible choices: >> - static >> - shared > > +1 > I believe that simplification is the way go. > >> This would allow us to remove one file (rte.sharelib.mk) and have a >> single file with archive/linking rules. >> >> For the convenience of linking against a single library instead of the >> multiple dpdk libraries, there are a few ways to go around it: >> - for combined static lib, we can either have a script to re-archive >> all libraries into a single/combined library (ie. extract all archives >> into one directory, the re-archive all objects into a combined library), >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). Would the linker script be provided in the repository or would it be the responsibility of people building against the DPDK? If I'd need to make a linker script with the list of libraries to link against, might as well put that list in my SConstruct / Makefile and be done with it. So the "write your own linker script" and "just deal with separate libraries" options don't seem that different to me. Let me ask you something - I understand your concerns about simplifying Makefiles and the concerns about versioning. How significant is the "separate libs" use case? And especially the "separate libs" in the current division of the code / libraries? I counted about ~30 libs in 1.8.0 under build/lib. Are there people using librte_eal without rte_malloc? Or rte_malloc without rte_mempool? I noticed that some examples I built ended up using --whole-archive -lrte_eal -lrte_etc.... To me, --whole-archive is one way of saying "we have lots of libraries with obscure dependencies", maybe reducing the number of libs might also be a way to make the combined lib unnecessary? I wouldn't bother with the combined lib if I had 3-4 libs to link against instead of the number of libs needed now. Just asking - obviously you guys are maintaining the code and know best, but I want to better understand the context from your side, as opposed to my (selfish) user perspective :). Thanks, Stefan. >> - for combined shared lib, we can use a linker script (ie. INPUT ( >> -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a >> global version map (either somehow merging all independent version maps >> or maintaining a global version map). >> >> My preference would be to remove the combined libs as a build config >> option, then either add scripts to create those linker scripts or >> document it so users know how to create their own linker scripts. >> This would simplify the build process and still be able to provide the >> convenience of the combined library by using a linker script. >> >> Comments? > > You're right about the word convenience. > There are many ways to provide such convenience. > The first one is to simply use the DPDK makefiles which abstract linking problems. > If using DPDK framework is not an option, we can add new conveniences like > scripts or pkgconfig support. > ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <CACKs7VBNmmdPoBcv-vPpn-HVQr2Nd2Gr_2shTuqdh2L1MsfY_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <CACKs7VBNmmdPoBcv-vPpn-HVQr2Nd2Gr_2shTuqdh2L1MsfY_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-03-18 15:52 ` Gonzalez Monroy, Sergio 2015-03-18 16:48 ` Neil Horman 1 sibling, 0 replies; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-18 15:52 UTC (permalink / raw) To: Stefan Puiu; +Cc: dev-VfR2kkLFssw On 18/03/2015 15:30, Stefan Puiu wrote: > Hi, > > On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon > <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote: >> Hi Sergio, >> >> Thank you for explaining the situation. >> >> 2015-03-18 12:11, Gonzalez Monroy, Sergio: >>> Given that the patch to remove combined libraries is not welcome, I'll >>> try to explain the current situation so we can agree on the way forward. >>> >>> Currently we have build config option for shared libraries and combined >>> libraries. Thus, this results in four possible combinations when >>> building dpdk: >>> - not combined static >>> - not combined shared >>> - combined static >>> - combined shared >>> >>> The makefile rules/targets for combined are different than for not >>> combined. Thus, we currently have two different files for >>> archive/linking (rte.lib.mk and rte.sharelib.mk). >>> >>> Since having versioning, combined shared libraries build will be broken >>> the moment we add a versioned API, as we do not have a global version >>> map that we use when linking such library. >>> Also in my opinion, we would want to prevent users linking against a >>> combined libdpdk.so that may have different features built-in, with the >>> corresponding debugging difficulties when users >>> report different problems/errors. I think this would defeat many of the >>> advantages of using shared libraries. >>> >>> By removing the combined library build option, we would simplify the >>> build system with only two possible choices: >>> - static >>> - shared >> +1 >> I believe that simplification is the way go. >> >>> This would allow us to remove one file (rte.sharelib.mk) and have a >>> single file with archive/linking rules. >>> >>> For the convenience of linking against a single library instead of the >>> multiple dpdk libraries, there are a few ways to go around it: >>> - for combined static lib, we can either have a script to re-archive >>> all libraries into a single/combined library (ie. extract all archives >>> into one directory, the re-archive all objects into a combined library), >>> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). > Would the linker script be provided in the repository or would it be > the responsibility of people building against the DPDK? If I'd need to > make a linker script with the list of libraries to link against, might > as well put that list in my SConstruct / Makefile and be done with it. > So the "write your own linker script" and "just deal with separate > libraries" options don't seem that different to me. > > Let me ask you something - I understand your concerns about > simplifying Makefiles and the concerns about versioning. How > significant is the "separate libs" use case? And especially the > "separate libs" in the current division of the code / libraries? I > counted about ~30 libs in 1.8.0 under build/lib. Are there people > using librte_eal without rte_malloc? Or rte_malloc without > rte_mempool? > > I noticed that some examples I built ended up using --whole-archive > -lrte_eal -lrte_etc.... To me, --whole-archive is one way of saying > "we have lots of libraries with obscure dependencies", maybe reducing > the number of libs might also be a way to make the combined lib > unnecessary? I wouldn't bother with the combined lib if I had 3-4 libs > to link against instead of the number of libs needed now. > > Just asking - obviously you guys are maintaining the code and know > best, but I want to better understand the context from your side, as > opposed to my (selfish) user perspective :). > > Thanks, > Stefan. > Some of this questions have been discussed previously: http://dpdk.org/ml/archives/dev/2014-October/007389.html http://dpdk.org/ml/archives/dev/2015-January/010917.html http://dpdk.org/ml/archives/dev/2015-January/011912.html I think those threads will provide enough context but as a very general summary, only eal, malloc, mempool and ring would have circular dependencies and you could consider them as 'core' libraries in the sense that almost (if not all) dpdk apps are going to be linked against them. Most of dpdk libraries are optional features that your application may or may not be using. Sergio >>> - for combined shared lib, we can use a linker script (ie. INPUT ( >>> -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a >>> global version map (either somehow merging all independent version maps >>> or maintaining a global version map). >>> >>> My preference would be to remove the combined libs as a build config >>> option, then either add scripts to create those linker scripts or >>> document it so users know how to create their own linker scripts. >>> This would simplify the build process and still be able to provide the >>> convenience of the combined library by using a linker script. >>> >>> Comments? >> You're right about the word convenience. >> There are many ways to provide such convenience. >> The first one is to simply use the DPDK makefiles which abstract linking problems. >> If using DPDK framework is not an option, we can add new conveniences like >> scripts or pkgconfig support. >> ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <CACKs7VBNmmdPoBcv-vPpn-HVQr2Nd2Gr_2shTuqdh2L1MsfY_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-03-18 15:52 ` Gonzalez Monroy, Sergio @ 2015-03-18 16:48 ` Neil Horman 1 sibling, 0 replies; 63+ messages in thread From: Neil Horman @ 2015-03-18 16:48 UTC (permalink / raw) To: Stefan Puiu; +Cc: dev-VfR2kkLFssw On Wed, Mar 18, 2015 at 05:30:12PM +0200, Stefan Puiu wrote: > Hi, > > On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon > <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote: > > Hi Sergio, > > > > Thank you for explaining the situation. > > > > 2015-03-18 12:11, Gonzalez Monroy, Sergio: > >> Given that the patch to remove combined libraries is not welcome, I'll > >> try to explain the current situation so we can agree on the way forward. > >> > >> Currently we have build config option for shared libraries and combined > >> libraries. Thus, this results in four possible combinations when > >> building dpdk: > >> - not combined static > >> - not combined shared > >> - combined static > >> - combined shared > >> > >> The makefile rules/targets for combined are different than for not > >> combined. Thus, we currently have two different files for > >> archive/linking (rte.lib.mk and rte.sharelib.mk). > >> > >> Since having versioning, combined shared libraries build will be broken > >> the moment we add a versioned API, as we do not have a global version > >> map that we use when linking such library. > >> Also in my opinion, we would want to prevent users linking against a > >> combined libdpdk.so that may have different features built-in, with the > >> corresponding debugging difficulties when users > >> report different problems/errors. I think this would defeat many of the > >> advantages of using shared libraries. > >> > >> By removing the combined library build option, we would simplify the > >> build system with only two possible choices: > >> - static > >> - shared > > > > +1 > > I believe that simplification is the way go. > > > >> This would allow us to remove one file (rte.sharelib.mk) and have a > >> single file with archive/linking rules. > >> > >> For the convenience of linking against a single library instead of the > >> multiple dpdk libraries, there are a few ways to go around it: > >> - for combined static lib, we can either have a script to re-archive > >> all libraries into a single/combined library (ie. extract all archives > >> into one directory, the re-archive all objects into a combined library), > >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). > > Would the linker script be provided in the repository or would it be > the responsibility of people building against the DPDK? If I'd need to > make a linker script with the list of libraries to link against, might > as well put that list in my SConstruct / Makefile and be done with it. > So the "write your own linker script" and "just deal with separate > libraries" options don't seem that different to me. > just to level set, I think you're thinking of a linker script in too grand a scale. Technically what we're proposing is a linker script, but its literally a single line. If you want an example take a look at /usr/lib64/libc.so. that said, I think it makes more sense for the linker script in question to be part of the dpdk distribution so that the combined library name picks up new libraries as they are created. > Let me ask you something - I understand your concerns about > simplifying Makefiles and the concerns about versioning. How > significant is the "separate libs" use case? And especially the > "separate libs" in the current division of the code / libraries? I > counted about ~30 libs in 1.8.0 under build/lib. Are there people > using librte_eal without rte_malloc? Or rte_malloc without > rte_mempool? > Highly doubtful/impossible since they are explicitly dependent on one another. > I noticed that some examples I built ended up using --whole-archive > -lrte_eal -lrte_etc.... To me, --whole-archive is one way of saying > "we have lots of libraries with obscure dependencies", maybe reducing > the number of libs might also be a way to make the combined lib > unnecessary? I wouldn't bother with the combined lib if I had 3-4 libs > to link against instead of the number of libs needed now. > This isn't a bad suggestion. combining the low level malloc/mempool/eal libraries into a libdpdk_core probably makes sense. Not sure if doing it right now makes sense (this close to the release). But as a next release goal that seems reasonable. Neil ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options 2015-03-18 12:59 ` Thomas Monjalon 2015-03-18 15:30 ` Stefan Puiu @ 2015-03-26 8:52 ` Gonzalez Monroy, Sergio [not found] ` <5513C8CD.80408-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 63+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-03-26 8:52 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev-VfR2kkLFssw On 18/03/2015 12:59, Thomas Monjalon wrote: > Hi Sergio, > > Thank you for explaining the situation. > > 2015-03-18 12:11, Gonzalez Monroy, Sergio: >> Given that the patch to remove combined libraries is not welcome, I'll >> try to explain the current situation so we can agree on the way forward. >> >> Currently we have build config option for shared libraries and combined >> libraries. Thus, this results in four possible combinations when >> building dpdk: >> - not combined static >> - not combined shared >> - combined static >> - combined shared >> >> The makefile rules/targets for combined are different than for not >> combined. Thus, we currently have two different files for >> archive/linking (rte.lib.mk and rte.sharelib.mk). >> >> Since having versioning, combined shared libraries build will be broken >> the moment we add a versioned API, as we do not have a global version >> map that we use when linking such library. >> Also in my opinion, we would want to prevent users linking against a >> combined libdpdk.so that may have different features built-in, with the >> corresponding debugging difficulties when users >> report different problems/errors. I think this would defeat many of the >> advantages of using shared libraries. >> >> By removing the combined library build option, we would simplify the >> build system with only two possible choices: >> - static >> - shared > +1 > I believe that simplification is the way go. > >> This would allow us to remove one file (rte.sharelib.mk) and have a >> single file with archive/linking rules. >> >> For the convenience of linking against a single library instead of the >> multiple dpdk libraries, there are a few ways to go around it: >> - for combined static lib, we can either have a script to re-archive >> all libraries into a single/combined library (ie. extract all archives >> into one directory, the re-archive all objects into a combined library), >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). >> - for combined shared lib, we can use a linker script (ie. INPUT ( >> -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a >> global version map (either somehow merging all independent version maps >> or maintaining a global version map). >> >> My preference would be to remove the combined libs as a build config >> option, then either add scripts to create those linker scripts or >> document it so users know how to create their own linker scripts. >> This would simplify the build process and still be able to provide the >> convenience of the combined library by using a linker script. >> >> Comments? > You're right about the word convenience. > There are many ways to provide such convenience. > The first one is to simply use the DPDK makefiles which abstract linking problems. > If using DPDK framework is not an option, we can add new conveniences like > scripts or pkgconfig support. > So for v3, do we provide such script/pkgconfig or just documentation on how to create it? Sergio ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <5513C8CD.80408-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <5513C8CD.80408-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> @ 2015-03-26 10:30 ` Neil Horman 0 siblings, 0 replies; 63+ messages in thread From: Neil Horman @ 2015-03-26 10:30 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Thu, Mar 26, 2015 at 08:52:29AM +0000, Gonzalez Monroy, Sergio wrote: > On 18/03/2015 12:59, Thomas Monjalon wrote: > >Hi Sergio, > > > >Thank you for explaining the situation. > > > >2015-03-18 12:11, Gonzalez Monroy, Sergio: > >>Given that the patch to remove combined libraries is not welcome, I'll > >>try to explain the current situation so we can agree on the way forward. > >> > >>Currently we have build config option for shared libraries and combined > >>libraries. Thus, this results in four possible combinations when > >>building dpdk: > >>- not combined static > >>- not combined shared > >>- combined static > >>- combined shared > >> > >>The makefile rules/targets for combined are different than for not > >>combined. Thus, we currently have two different files for > >>archive/linking (rte.lib.mk and rte.sharelib.mk). > >> > >>Since having versioning, combined shared libraries build will be broken > >>the moment we add a versioned API, as we do not have a global version > >>map that we use when linking such library. > >>Also in my opinion, we would want to prevent users linking against a > >>combined libdpdk.so that may have different features built-in, with the > >>corresponding debugging difficulties when users > >>report different problems/errors. I think this would defeat many of the > >>advantages of using shared libraries. > >> > >>By removing the combined library build option, we would simplify the > >>build system with only two possible choices: > >>- static > >>- shared > >+1 > >I believe that simplification is the way go. > > > >>This would allow us to remove one file (rte.sharelib.mk) and have a > >>single file with archive/linking rules. > >> > >>For the convenience of linking against a single library instead of the > >>multiple dpdk libraries, there are a few ways to go around it: > >> - for combined static lib, we can either have a script to re-archive > >>all libraries into a single/combined library (ie. extract all archives > >>into one directory, the re-archive all objects into a combined library), > >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). > >>- for combined shared lib, we can use a linker script (ie. INPUT ( > >>-lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a > >>global version map (either somehow merging all independent version maps > >>or maintaining a global version map). > >> > >>My preference would be to remove the combined libs as a build config > >>option, then either add scripts to create those linker scripts or > >>document it so users know how to create their own linker scripts. > >>This would simplify the build process and still be able to provide the > >>convenience of the combined library by using a linker script. > >> > >>Comments? > >You're right about the word convenience. > >There are many ways to provide such convenience. > >The first one is to simply use the DPDK makefiles which abstract linking problems. > >If using DPDK framework is not an option, we can add new conveniences like > >scripts or pkgconfig support. > > > So for v3, do we provide such script/pkgconfig or just documentation on how > to create it? > > Sergio > I think the former makes the most sense, personally. Provide a script or automatically build the combined lib script during the build. Neil ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH v2 1/4] mk: Remove combined library and related options [not found] ` <55096B86.7040303-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-18 12:59 ` Thomas Monjalon @ 2015-03-18 16:41 ` Neil Horman 1 sibling, 0 replies; 63+ messages in thread From: Neil Horman @ 2015-03-18 16:41 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev-VfR2kkLFssw On Wed, Mar 18, 2015 at 12:11:50PM +0000, Gonzalez Monroy, Sergio wrote: > On 12/03/2015 16:27, Sergio Gonzalez Monroy wrote: > >Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME. > > > >Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > >--- > > config/common_bsdapp | 6 -- > > config/common_linuxapp | 6 -- > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > 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 | 9 --- > > 9 files changed, 175 deletions(-) > > delete mode 100644 mk/rte.sharelib.mk > > > >diff --git a/config/common_bsdapp b/config/common_bsdapp > >index 8ff4dc2..7ee5ecf 100644 > >--- a/config/common_bsdapp > >+++ b/config/common_bsdapp > >@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > > CONFIG_RTE_BUILD_SHARED_LIB=n > > # > >-# Combine to one single library > >-# > >-CONFIG_RTE_BUILD_COMBINE_LIBS=n > >-CONFIG_RTE_LIBNAME=intel_dpdk > >- > >-# > > # Compile Environment Abstraction Layer > > # > > CONFIG_RTE_LIBRTE_EAL=y > >diff --git a/config/common_linuxapp b/config/common_linuxapp > >index 97f1c9e..ae13805 100644 > >--- a/config/common_linuxapp > >+++ b/config/common_linuxapp > >@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n > > CONFIG_RTE_BUILD_SHARED_LIB=n > > # > >-# Combine to one single library > >-# > >-CONFIG_RTE_BUILD_COMBINE_LIBS=n > >-CONFIG_RTE_LIBNAME="intel_dpdk" > >- > >-# > > # Compile Environment Abstraction Layer > > # > > CONFIG_RTE_LIBRTE_EAL=y > >diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8-linuxapp-gcc > >index d97a885..f1af518 100644 > >--- a/config/defconfig_ppc_64-power8-linuxapp-gcc > >+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc > >@@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y > > CONFIG_RTE_TOOLCHAIN="gcc" > > CONFIG_RTE_TOOLCHAIN_GCC=y > >-CONFIG_RTE_LIBNAME="powerpc_dpdk" > >- > > # Note: Power doesn't have this support > > CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n > >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 63a41e2..e2baa49 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..7b6f53d 100644 > >--- a/mk/rte.vars.mk > >+++ b/mk/rte.vars.mk > >@@ -67,15 +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:"%"=%) > >-ifeq ($(RTE_LIBNAME),) > >-RTE_LIBNAME := intel_dpdk > > endif > > # RTE_TARGET is deducted from config when we are building the SDK. > Given that the patch to remove combined libraries is not welcome, I'll try > to explain the current situation so we can agree on the way forward. > > Currently we have build config option for shared libraries and combined > libraries. Thus, this results in four possible combinations when building > dpdk: > - not combined static > - not combined shared > - combined static > - combined shared > > The makefile rules/targets for combined are different than for not combined. > Thus, we currently have two different files for archive/linking (rte.lib.mk > and rte.sharelib.mk). > > Since having versioning, combined shared libraries build will be broken the > moment we add a versioned API, as we do not have a global version map that > we use when linking such library. > Also in my opinion, we would want to prevent users linking against a > combined libdpdk.so that may have different features built-in, with the > corresponding debugging difficulties when users > report different problems/errors. I think this would defeat many of the > advantages of using shared libraries. > > By removing the combined library build option, we would simplify the build > system with only two possible choices: > - static > - shared > > This would allow us to remove one file (rte.sharelib.mk) and have a single > file with archive/linking rules. > > For the convenience of linking against a single library instead of the > multiple dpdk libraries, there are a few ways to go around it: > - for combined static lib, we can either have a script to re-archive all > libraries into a single/combined library (ie. extract all archives into one > directory, the re-archive all objects into a combined library), > or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). > - for combined shared lib, we can use a linker script (ie. INPUT ( -lrte_eal > -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a global > version map (either somehow merging all independent version maps > or maintaining a global version map). > > My preference would be to remove the combined libs as a build config option, > then either add scripts to create those linker scripts or document it so > users know how to create their own linker scripts. > This would simplify the build process and still be able to provide the > convenience of the combined library by using a linker script. > > Comments? > I agree, the combined libs config option creates significant build environment complications that don't need to be there (given that in both the static and shared cases, post processing gives us the same convieniences). The comments on this thread have suggested that the combined libraries are mostly seen as adventageous for their convienience, so if we can provide that convienience in another way that solves other problems we have (versioning of a combined library), and reduce build complexity, we should do it. Neil > Sergio > ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH v2 2/4] lib: Set LDLIBS for each library [not found] ` <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-12 16:27 ` [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy @ 2015-03-12 16:27 ` Sergio Gonzalez Monroy 2015-03-12 16:28 ` [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy 2015-03-12 16:28 ` [PATCH v2 4/4] mk: update LDLIBS for app building Sergio Gonzalez Monroy 3 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-03-12 16:27 UTC (permalink / raw) To: dev-VfR2kkLFssw When creating shared libraries, each library will be linked against their dependant libraries, which are specified by new LDLIBS var. 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 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 but eal and updates DEPDIRS of some libraries. Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- lib/librte_acl/Makefile | 2 ++ lib/librte_cfgfile/Makefile | 2 ++ lib/librte_cmdline/Makefile | 2 ++ lib/librte_distributor/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_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_i40e/Makefile | 2 ++ lib/librte_pmd_ixgbe/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_ring/Makefile | 2 ++ lib/librte_sched/Makefile | 2 ++ lib/librte_table/Makefile | 4 ++++ lib/librte_timer/Makefile | 2 ++ lib/librte_vhost/Makefile | 7 ++++--- 34 files changed, 84 insertions(+), 5 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_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_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_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 9a5cd33..40de37c 100644 --- a/lib/librte_pmd_ixgbe/Makefile +++ b/lib/librte_pmd_ixgbe/Makefile @@ -90,6 +90,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_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_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 52f6575..b389f0e 100644 --- a/lib/librte_vhost/Makefile +++ b/lib/librte_vhost/Makefile @@ -39,9 +39,10 @@ EXPORT_MAP := rte_vhost_version.map LIBABIVER := 1 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64 -CFLAGS += -I vhost_cuse -lfuse -CFLAGS += -I vhost_user -LDFLAGS += -lfuse +CFLAGS += -I vhost_cuse -I vhost_user + +LDLIBS += -lrte_eal -lrte_mbuf -lethdev -lfuse + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := virtio-net.c vhost_rxtx.c #SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_cuse/vhost-net-cdev.c vhost_cuse/virtio-net-cdev.c vhost_cuse/eventfd_copy.c -- 1.9.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries [not found] ` <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2015-03-12 16:27 ` [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy 2015-03-12 16:27 ` [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy @ 2015-03-12 16:28 ` Sergio Gonzalez Monroy 2015-03-12 16:28 ` [PATCH v2 4/4] mk: update LDLIBS for app building Sergio Gonzalez Monroy 3 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-03-12 16:28 UTC (permalink / raw) To: dev-VfR2kkLFssw 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- 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 related [flat|nested] 63+ messages in thread
* [PATCH v2 4/4] mk: update LDLIBS for app building [not found] ` <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ` (2 preceding siblings ...) 2015-03-12 16:28 ` [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy @ 2015-03-12 16:28 ` Sergio Gonzalez Monroy 3 siblings, 0 replies; 63+ messages in thread From: Sergio Gonzalez Monroy @ 2015-03-12 16:28 UTC (permalink / raw) To: dev-VfR2kkLFssw 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- lib/librte_jobstats/Makefile | 2 ++ lib/librte_pmd_fm10k/Makefile | 2 ++ lib/librte_pmd_mlx4/Makefile | 2 ++ lib/librte_pmd_null/Makefile | 2 ++ lib/librte_reorder/Makefile | 2 ++ mk/rte.app.mk | 57 +++++++++++++++++++++++-------------------- 6 files changed, 40 insertions(+), 27 deletions(-) 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_pmd_fm10k/Makefile b/lib/librte_pmd_fm10k/Makefile index 998bf23..618235a 100644 --- a/lib/librte_pmd_fm10k/Makefile +++ b/lib/librte_pmd_fm10k/Makefile @@ -79,6 +79,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_mlx4/Makefile b/lib/librte_pmd_mlx4/Makefile index 6666813..9193f05 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_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/mk/rte.app.mk b/mk/rte.app.mk index e2baa49..7e225fd 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,15 +150,12 @@ LDLIBS += -lm LDLIBS += -lrt endif -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) -LDLIBS += -lrte_vhost -endif - ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) LDLIBS += -lpcap endif ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y) +LDLIBS += -lrte_vhost LDLIBS += -lfuse endif @@ -143,8 +163,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 +179,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 +198,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 +244,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 related [flat|nested] 63+ messages in thread
end of thread, other threads:[~2015-03-26 10:30 UTC | newest]
Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-29 15:20 [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
[not found] ` <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-01-29 15:20 ` [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 2/8] core: create new librte_core Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 3/8] mk: new corelib makefile Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 4/8] lib: update DEPDIRS variable Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 5/8] lib: set LDLIBS for each library Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 6/8] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 7/8] mk: update LDLIBS for app building Sergio Gonzalez Monroy
2015-01-29 15:20 ` [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy
2015-01-29 16:38 ` [PATCH 0/8] Improve build process Neil Horman
[not found] ` <20150129163859.GE1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-01-29 17:02 ` Thomas Monjalon
2015-01-29 17:04 ` Gonzalez Monroy, Sergio
[not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F43D9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-01-29 19:45 ` Neil Horman
[not found] ` <20150129194539.GG1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-01-30 13:39 ` Gonzalez Monroy, Sergio
[not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F453D7-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-01-30 14:05 ` Neil Horman
[not found] ` <20150130140507.GA2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-01-30 17:38 ` Gonzalez Monroy, Sergio
[not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F45534-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-01-30 18:12 ` Neil Horman
[not found] ` <20150130181249.GC2664-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-02-11 11:11 ` Gonzalez Monroy, Sergio
[not found] ` <91383E96CE459D47BCE92EFBF5CE73B004F4AB9B-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-12 5:41 ` Neil Horman
[not found] ` <20150212054105.GC5504-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2015-02-12 9:17 ` Gonzalez Monroy, Sergio
[not found] ` <54DC6FB3.8020608-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-12 12:16 ` Neil Horman
2015-02-12 9:22 ` Panu Matilainen
[not found] ` <54DC70F3.4020902-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-12 10:03 ` Gonzalez Monroy, Sergio
[not found] ` <54DC7A87.1090208-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-12 12:23 ` Neil Horman
[not found] ` <20150212122354.GB8729-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2015-02-12 14:07 ` Panu Matilainen
[not found] ` <54DCB3B6.1010204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-12 15:52 ` Neil Horman
[not found] ` <20150212155225.GB4634-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2015-02-13 10:14 ` Panu Matilainen
[not found] ` <54DDCE68.7090400-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-13 11:08 ` Gonzalez Monroy, Sergio
[not found] ` <54DDDB12.3090100-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-13 12:51 ` Neil Horman
[not found] ` <20150213125142.GA11979-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2015-02-20 14:31 ` Gonzalez Monroy, Sergio
[not found] ` <54E74548.7010805-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-22 23:37 ` Neil Horman
[not found] ` <20150222233740.GB31293-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2015-02-23 10:25 ` Gonzalez Monroy, Sergio
[not found] ` <54EAFFFD.5000200-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-23 13:52 ` Neil Horman
[not found] ` <20150223135205.GA19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-02-23 14:58 ` Gonzalez Monroy, Sergio
[not found] ` <54EB4016.1040204-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-23 18:23 ` Neil Horman
[not found] ` <20150223182319.GC19230-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-02-24 13:24 ` Gonzalez Monroy, Sergio
2015-03-12 16:27 ` [PATCH v2 0/4] " Sergio Gonzalez Monroy
[not found] ` <1426177681-16931-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-12 16:27 ` [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
[not found] ` <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-13 10:49 ` Kavanagh, Mark B
[not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52C87-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-13 11:19 ` Gonzalez Monroy, Sergio
[not found] ` <5502C7D9.2060503-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-13 11:34 ` Kavanagh, Mark B
[not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52D13-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-13 11:48 ` Gonzalez Monroy, Sergio
[not found] ` <5502CEAB.8060801-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-13 13:16 ` Kavanagh, Mark B
[not found] ` <DC5AD7FA266D86499789B1BCAEC715F846D52DDA-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-13 14:11 ` Gonzalez Monroy, Sergio
2015-03-13 13:17 ` Neil Horman
[not found] ` <20150313131719.GA28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-03-13 14:12 ` Stefan Puiu
[not found] ` <CACKs7VAOZ-e6=jC_kUJC0eO5wfj5r3uaPOR3QGyHpzxC_vLttA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-13 15:18 ` Neil Horman
[not found] ` <20150313151855.GG28191-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-03-13 15:28 ` Gonzalez Monroy, Sergio
[not found] ` <55030200.4070505-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-13 16:16 ` Neil Horman
2015-03-13 16:07 ` Stephen Hemminger
2015-03-13 16:32 ` Neil Horman
2015-03-13 16:38 ` Gonzalez Monroy, Sergio
2015-03-18 12:11 ` Gonzalez Monroy, Sergio
[not found] ` <55096B86.7040303-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-18 12:59 ` Thomas Monjalon
2015-03-18 15:30 ` Stefan Puiu
[not found] ` <CACKs7VBNmmdPoBcv-vPpn-HVQr2Nd2Gr_2shTuqdh2L1MsfY_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-18 15:52 ` Gonzalez Monroy, Sergio
2015-03-18 16:48 ` Neil Horman
2015-03-26 8:52 ` Gonzalez Monroy, Sergio
[not found] ` <5513C8CD.80408-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-03-26 10:30 ` Neil Horman
2015-03-18 16:41 ` Neil Horman
2015-03-12 16:27 ` [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy
2015-03-12 16:28 ` [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-03-12 16:28 ` [PATCH v2 4/4] mk: update LDLIBS for app building Sergio Gonzalez Monroy
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.