[dpdk-dev] [PATCH 0/8] Improve build process

DPDK patches and discussions
 help / color / mirror / Atom feed

* [dpdk-dev] [PATCH 0/8] Improve build process
@ 2015-01-29 15:20 Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy
                   ` (9 more replies)
  0 siblings, 10 replies; 63+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-01-29 15:20 UTC (permalink / raw)
  To: dev

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

* [dpdk-dev] [PATCH 1/8] mk: remove combined library and related options
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
@ 2015-01-29 15:20 ` Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [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

Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 2/8] core: create new librte_core
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [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 ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 3/8] mk: new corelib makefile
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [PATCH 2/8] core: create new librte_core Sergio Gonzalez Monroy
@ 2015-01-29 15:20 ` Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 4/8] lib: update DEPDIRS variable
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (2 preceding siblings ...)
  2015-01-29 15:20 ` [dpdk-dev] [PATCH 3/8] mk: new corelib makefile Sergio Gonzalez Monroy
@ 2015-01-29 15:20 ` Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 5/8] lib: set LDLIBS for each library
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (3 preceding siblings ...)
  2015-01-29 15:20 ` [dpdk-dev] [PATCH 4/8] lib: update DEPDIRS variable Sergio Gonzalez Monroy
@ 2015-01-29 15:20 ` Sergio Gonzalez Monroy
  2015-01-29 15:20 ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 6/8] mk: use LDLIBS when linking shared libraries
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (4 preceding siblings ...)
  2015-01-29 15:20 ` [dpdk-dev] [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 ` [dpdk-dev] [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

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@intel.com>
---
 mk/rte.lib.mk | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 7/8] mk: update LDLIBS for app building
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (5 preceding siblings ...)
  2015-01-29 15:20 ` [dpdk-dev] [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 ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (6 preceding siblings ...)
  2015-01-29 15:20 ` [dpdk-dev] [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 ` [dpdk-dev] [PATCH 0/8] Improve build process Neil Horman
  2015-03-12 16:27 ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (7 preceding siblings ...)
  2015-01-29 15:20 ` [dpdk-dev] [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy
@ 2015-01-29 16:38 ` Neil Horman
  2015-01-29 17:02   ` Thomas Monjalon
  2015-01-29 17:04   ` Gonzalez Monroy, Sergio
  2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
  9 siblings, 2 replies; 63+ messages in thread
From: Neil Horman @ 2015-01-29 16:38 UTC (permalink / raw)
  To: Sergio Gonzalez Monroy; +Cc: dev

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-29 16:38 ` [dpdk-dev] [PATCH 0/8] Improve build process Neil Horman
@ 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

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: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-29 16:38 ` [dpdk-dev] [PATCH 0/8] Improve build process Neil Horman
  2015-01-29 17:02   ` Thomas Monjalon
@ 2015-01-29 17:04   ` Gonzalez Monroy, Sergio
  2015-01-29 19:45     ` Neil Horman
  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

> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Thursday, January 29, 2015 4:39 PM
> To: Gonzalez Monroy, Sergio
> Cc: dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-29 17:04   ` Gonzalez Monroy, Sergio
@ 2015-01-29 19:45     ` Neil Horman
  2015-01-30 13:39       ` Gonzalez Monroy, Sergio
  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

On Thu, Jan 29, 2015 at 05:04:20PM +0000, Gonzalez Monroy, Sergio wrote:
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Thursday, January 29, 2015 4:39 PM
> > To: Gonzalez Monroy, Sergio
> > Cc: dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-29 19:45     ` Neil Horman
@ 2015-01-30 13:39       ` Gonzalez Monroy, Sergio
  2015-01-30 14:05         ` Neil Horman
  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

> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Thursday, January 29, 2015 7:46 PM
> To: Gonzalez Monroy, Sergio
> Cc: dev@dpdk.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@tuxdriver.com]
> > > Sent: Thursday, January 29, 2015 4:39 PM
> > > To: Gonzalez Monroy, Sergio
> > > Cc: dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-30 13:39       ` Gonzalez Monroy, Sergio
@ 2015-01-30 14:05         ` Neil Horman
  2015-01-30 17:38           ` Gonzalez Monroy, Sergio
  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

On Fri, Jan 30, 2015 at 01:39:28PM +0000, Gonzalez Monroy, Sergio wrote:
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Thursday, January 29, 2015 7:46 PM
> > To: Gonzalez Monroy, Sergio
> > Cc: dev@dpdk.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@tuxdriver.com]
> > > > Sent: Thursday, January 29, 2015 4:39 PM
> > > > To: Gonzalez Monroy, Sergio
> > > > Cc: dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-30 14:05         ` Neil Horman
@ 2015-01-30 17:38           ` Gonzalez Monroy, Sergio
  2015-01-30 18:12             ` Neil Horman
  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

> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Friday, January 30, 2015 2:05 PM
> To: Gonzalez Monroy, Sergio
> Cc: Thomas Monjalon; dev@dpdk.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@tuxdriver.com]
> > > Sent: Thursday, January 29, 2015 7:46 PM
> > > To: Gonzalez Monroy, Sergio
> > > Cc: dev@dpdk.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@tuxdriver.com]
> > > > > Sent: Thursday, January 29, 2015 4:39 PM
> > > > > To: Gonzalez Monroy, Sergio
> > > > > Cc: dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-30 17:38           ` Gonzalez Monroy, Sergio
@ 2015-01-30 18:12             ` Neil Horman
  2015-02-11 11:11               ` Gonzalez Monroy, Sergio
  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

On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote:
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Friday, January 30, 2015 2:05 PM
> > To: Gonzalez Monroy, Sergio
> > Cc: Thomas Monjalon; dev@dpdk.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@tuxdriver.com]
> > > > Sent: Thursday, January 29, 2015 7:46 PM
> > > > To: Gonzalez Monroy, Sergio
> > > > Cc: dev@dpdk.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@tuxdriver.com]
> > > > > > Sent: Thursday, January 29, 2015 4:39 PM
> > > > > > To: Gonzalez Monroy, Sergio
> > > > > > Cc: dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-01-30 18:12             ` Neil Horman
@ 2015-02-11 11:11               ` Gonzalez Monroy, Sergio
  2015-02-12  5:41                 ` Neil Horman
  2015-02-12  9:22                 ` Panu Matilainen
  0 siblings, 2 replies; 63+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-02-11 11:11 UTC (permalink / raw)
  To: Neil Horman; +Cc: dev

> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Friday, January 30, 2015 6:13 PM
> To: Gonzalez Monroy, Sergio
> Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-11 11:11               ` Gonzalez Monroy, Sergio
@ 2015-02-12  5:41                 ` Neil Horman
  2015-02-12  9:17                   ` Gonzalez Monroy, Sergio
  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

On Wed, Feb 11, 2015 at 11:11:13AM +0000, Gonzalez Monroy, Sergio wrote:
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Friday, January 30, 2015 6:13 PM
> > To: Gonzalez Monroy, Sergio
> > Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12  5:41                 ` Neil Horman
@ 2015-02-12  9:17                   ` Gonzalez Monroy, Sergio
  2015-02-12 12:16                     ` Neil Horman
  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

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@tuxdriver.com]
>>> Sent: Friday, January 30, 2015 6:13 PM
>>> To: Gonzalez Monroy, Sergio
>>> Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12  9:17                   ` Gonzalez Monroy, Sergio
@ 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

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@tuxdriver.com]
> >>>Sent: Friday, January 30, 2015 6:13 PM
> >>>To: Gonzalez Monroy, Sergio
> >>>Cc: Thomas Monjalon; dev@dpdk.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: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-11 11:11               ` Gonzalez Monroy, Sergio
  2015-02-12  5:41                 ` Neil Horman
@ 2015-02-12  9:22                 ` Panu Matilainen
  2015-02-12 10:03                   ` Gonzalez Monroy, Sergio
  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

On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote:
>> From: Neil Horman [mailto:nhorman@tuxdriver.com]
>> Sent: Friday, January 30, 2015 6:13 PM
>> To: Gonzalez Monroy, Sergio
>> Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12  9:22                 ` Panu Matilainen
@ 2015-02-12 10:03                   ` Gonzalez Monroy, Sergio
  2015-02-12 12:23                     ` Neil Horman
  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

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@tuxdriver.com]
>>> Sent: Friday, January 30, 2015 6:13 PM
>>> To: Gonzalez Monroy, Sergio
>>> Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12 10:03                   ` Gonzalez Monroy, Sergio
@ 2015-02-12 12:23                     ` Neil Horman
  2015-02-12 14:07                       ` Panu Matilainen
  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

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@tuxdriver.com]
> >>>Sent: Friday, January 30, 2015 6:13 PM
> >>>To: Gonzalez Monroy, Sergio
> >>>Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12 12:23                     ` Neil Horman
@ 2015-02-12 14:07                       ` Panu Matilainen
  2015-02-12 15:52                         ` Neil Horman
  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

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@tuxdriver.com]
>>>>> Sent: Friday, January 30, 2015 6:13 PM
>>>>> To: Gonzalez Monroy, Sergio
>>>>> Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12 14:07                       ` Panu Matilainen
@ 2015-02-12 15:52                         ` Neil Horman
  2015-02-13 10:14                           ` Panu Matilainen
  0 siblings, 1 reply; 63+ messages in thread
From: Neil Horman @ 2015-02-12 15:52 UTC (permalink / raw)
  To: Panu Matilainen; +Cc: dev

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@tuxdriver.com]
> >>>>>Sent: Friday, January 30, 2015 6:13 PM
> >>>>>To: Gonzalez Monroy, Sergio
> >>>>>Cc: Thomas Monjalon; dev@dpdk.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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-12 15:52                         ` Neil Horman
@ 2015-02-13 10:14                           ` Panu Matilainen
  2015-02-13 11:08                             ` Gonzalez Monroy, Sergio
  0 siblings, 1 reply; 63+ messages in thread
From: Panu Matilainen @ 2015-02-13 10:14 UTC (permalink / raw)
  To: Neil Horman; +Cc: dev

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-13 10:14                           ` Panu Matilainen
@ 2015-02-13 11:08                             ` Gonzalez Monroy, Sergio
  2015-02-13 12:51                               ` Neil Horman
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-13 11:08                             ` Gonzalez Monroy, Sergio
@ 2015-02-13 12:51                               ` Neil Horman
  2015-02-20 14:31                                 ` Gonzalez Monroy, Sergio
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-13 12:51                               ` Neil Horman
@ 2015-02-20 14:31                                 ` Gonzalez Monroy, Sergio
  2015-02-22 23:37                                   ` Neil Horman
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-20 14:31                                 ` Gonzalez Monroy, Sergio
@ 2015-02-22 23:37                                   ` Neil Horman
  2015-02-23 10:25                                     ` Gonzalez Monroy, Sergio
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-22 23:37                                   ` Neil Horman
@ 2015-02-23 10:25                                     ` Gonzalez Monroy, Sergio
  2015-02-23 13:52                                       ` Neil Horman
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-23 10:25                                     ` Gonzalez Monroy, Sergio
@ 2015-02-23 13:52                                       ` Neil Horman
  2015-02-23 14:58                                         ` Gonzalez Monroy, Sergio
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-23 13:52                                       ` Neil Horman
@ 2015-02-23 14:58                                         ` Gonzalez Monroy, Sergio
  2015-02-23 18:23                                           ` Neil Horman
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-23 14:58                                         ` Gonzalez Monroy, Sergio
@ 2015-02-23 18:23                                           ` Neil Horman
  2015-02-24 13:24                                             ` Gonzalez Monroy, Sergio
  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

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

* Re: [dpdk-dev] [PATCH 0/8] Improve build process
  2015-02-23 18:23                                           ` Neil Horman
@ 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

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

* [dpdk-dev] [PATCH v2 0/4] Improve build process
  2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
                   ` (8 preceding siblings ...)
  2015-01-29 16:38 ` [dpdk-dev] [PATCH 0/8] Improve build process Neil Horman
@ 2015-03-12 16:27 ` Sergio Gonzalez Monroy
  2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
                     ` (3 more replies)
  9 siblings, 4 replies; 63+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-03-12 16:27 UTC (permalink / raw)
  To: dev

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

* [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
@ 2015-03-12 16:27   ` Sergio Gonzalez Monroy
  2015-03-13 10:49     ` Kavanagh, Mark B
                       ` (2 more replies)
  2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy
                     ` (2 subsequent siblings)
  3 siblings, 3 replies; 63+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-03-12 16:27 UTC (permalink / raw)
  To: dev

Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
@ 2015-03-13 10:49     ` Kavanagh, Mark B
  2015-03-13 11:19       ` Gonzalez Monroy, Sergio
  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

>---
> 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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 10:49     ` Kavanagh, Mark B
@ 2015-03-13 11:19       ` Gonzalez Monroy, Sergio
  2015-03-13 11:34         ` Kavanagh, Mark B
  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

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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 11:19       ` Gonzalez Monroy, Sergio
@ 2015-03-13 11:34         ` Kavanagh, Mark B
  2015-03-13 11:48           ` Gonzalez Monroy, Sergio
  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

>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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 11:34         ` Kavanagh, Mark B
@ 2015-03-13 11:48           ` Gonzalez Monroy, Sergio
  2015-03-13 13:16             ` Kavanagh, Mark B
  2015-03-13 13:17             ` Neil Horman
  0 siblings, 2 replies; 63+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-03-13 11:48 UTC (permalink / raw)
  To: Kavanagh, Mark B; +Cc: dev

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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 11:48           ` Gonzalez Monroy, Sergio
@ 2015-03-13 13:16             ` Kavanagh, Mark B
  2015-03-13 14:11               ` Gonzalez Monroy, Sergio
  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



>-----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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 13:16             ` Kavanagh, Mark B
@ 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

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@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.
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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 11:48           ` Gonzalez Monroy, Sergio
  2015-03-13 13:16             ` Kavanagh, Mark B
@ 2015-03-13 13:17             ` Neil Horman
  2015-03-13 14:12               ` Stefan Puiu
  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

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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 13:17             ` Neil Horman
@ 2015-03-13 14:12               ` Stefan Puiu
  2015-03-13 15:18                 ` Neil Horman
  0 siblings, 1 reply; 63+ messages in thread
From: Stefan Puiu @ 2015-03-13 14:12 UTC (permalink / raw)
  To: Neil Horman; +Cc: dev

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@tuxdriver.com> 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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 14:12               ` Stefan Puiu
@ 2015-03-13 15:18                 ` Neil Horman
  2015-03-13 15:28                   ` Gonzalez Monroy, Sergio
  0 siblings, 1 reply; 63+ messages in thread
From: Neil Horman @ 2015-03-13 15:18 UTC (permalink / raw)
  To: Stefan Puiu; +Cc: dev

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@tuxdriver.com> 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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 15:18                 ` Neil Horman
@ 2015-03-13 15:28                   ` Gonzalez Monroy, Sergio
  2015-03-13 16:16                     ` Neil Horman
  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

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@tuxdriver.com> 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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-13 15:28                   ` Gonzalez Monroy, Sergio
@ 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

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@tuxdriver.com> 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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
  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

On Thu, 12 Mar 2015 16:27:58 +0000
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:

> Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.
> 
> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> ---

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: [dpdk-dev] [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

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@intel.com> wrote:
> 
> > Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.
> > 
> > Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> > ---
> 
> 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: [dpdk-dev] [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

On 13/03/2015 16:07, Stephen Hemminger wrote:
> On Thu, 12 Mar 2015 16:27:58 +0000
> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>
>> Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.
>>
>> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>> ---
> 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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
  2015-03-13 10:49     ` Kavanagh, Mark B
  2015-03-13 16:07     ` Stephen Hemminger
@ 2015-03-18 12:11     ` Gonzalez Monroy, Sergio
  2015-03-18 12:59       ` Thomas Monjalon
  2015-03-18 16:41       ` Neil Horman
  2 siblings, 2 replies; 63+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-03-18 12:11 UTC (permalink / raw)
  To: dev

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@intel.com>
> ---
>   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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-18 12:11     ` Gonzalez Monroy, Sergio
@ 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

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: [dpdk-dev] [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-18 15:52           ` Gonzalez Monroy, Sergio
  2015-03-18 16:48           ` Neil Horman
  2015-03-26  8:52         ` Gonzalez Monroy, Sergio
  1 sibling, 2 replies; 63+ messages in thread
From: Stefan Puiu @ 2015-03-18 15:30 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev

Hi,

On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon
<thomas.monjalon@6wind.com> 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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-18 15:30         ` Stefan Puiu
@ 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

On 18/03/2015 15:30, Stefan Puiu wrote:
> Hi,
>
> On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> 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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-18 15:30         ` Stefan Puiu
  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

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@6wind.com> 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: [dpdk-dev] [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
  2015-03-26 10:30           ` Neil Horman
  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

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

* Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-26  8:52         ` Gonzalez Monroy, Sergio
@ 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

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: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
  2015-03-18 12:11     ` Gonzalez Monroy, Sergio
  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

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@intel.com>
> >---
> >  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

* [dpdk-dev] [PATCH v2 2/4] lib: Set LDLIBS for each library
  2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
  2015-03-12 16:27   ` [dpdk-dev] [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   ` [dpdk-dev] [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
  2015-03-12 16:28   ` [dpdk-dev] [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

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@intel.com>
---
 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	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries
  2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
  2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
  2015-03-12 16:27   ` [dpdk-dev] [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   ` [dpdk-dev] [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

This patch mainly makes use of the LDLIBS variable when linking shared
libraries, setting proper DT_NEEDED entries.

This patch also fixes a few nits like syntax highlighting, the command
string (O_TO_S_CMD) used for linking shared libraries and the displayed
of dependencies when debugging is enable (D).

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 mk/rte.lib.mk | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index d96101a..603badf 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -62,16 +62,19 @@ build: _postbuild
 
 exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1))))
 
+_LDLIBS := --as-needed $(LDLIBS) $(EXECENV_LDLIBS) --no-as-needed
+
 ifeq ($(LINK_USING_CC),1)
 # Override the definition of LD here, since we're linking with CC
 LD := $(CC) $(CPU_CFLAGS)
 _CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS))
+_LDLIBS := $(call linkerprefix,$(_LDLIBS))
 else
 _CPU_LDFLAGS := $(CPU_LDFLAGS)
 endif
 
 O_TO_A = $(AR) crus $(LIB) $(OBJS-y)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
+O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #')# fix syntax highlight
 O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)","  AR $(@)")
 O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
 O_TO_A_DO = @set -e; \
@@ -79,9 +82,11 @@ O_TO_A_DO = @set -e; \
 	$(O_TO_A) && \
 	echo $(O_TO_A_CMD) > $(call exe2cmd,$(@))
 
-O_TO_S = $(LD) $(_CPU_LDFLAGS) -shared $(OBJS-y) -Wl,-soname,$(LIB) -o $(LIB)
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
+O_TO_S = $(LD) $(_CPU_LDFLAGS) -L $(RTE_OUTPUT)/lib -Wl,-soname,$(LIB) \
+		 -shared $(OBJS-y) $(_LDLIBS) -o $(LIB)
+O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #')# fix syntax highlight
 O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)","  LD $(@)")
+O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
 O_TO_S_DO = @set -e; \
 	echo $(O_TO_S_DISP); \
 	$(O_TO_S) && \
@@ -100,7 +105,7 @@ ifeq ($(LIBABIVER),)
 endif
 	@[ -d $(dir $@) ] || mkdir -p $(dir $@)
 	$(if $(D),\
-		@echo -n "$< -> $@ " ; \
+		@echo -n "$? -> $@ " ; \
 		echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
 		echo -n "cmdline_changed=$(call boolean,$(call cmdline_changed,$(O_TO_S_STR))) " ; \
 		echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \
@@ -115,7 +120,7 @@ else
 $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
 	@[ -d $(dir $@) ] || mkdir -p $(dir $@)
 	$(if $(D),\
-	    @echo -n "$< -> $@ " ; \
+	    @echo -n "$? -> $@ " ; \
 	    echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
 	    echo -n "cmdline_changed=$(call boolean,$(call cmdline_changed,$(O_TO_A_STR))) " ; \
 	    echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \
-- 
1.9.3

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [dpdk-dev] [PATCH v2 4/4] mk: update LDLIBS for app building
  2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
                     ` (2 preceding siblings ...)
  2015-03-12 16:28   ` [dpdk-dev] [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

Given the circular dependencies between eal, malloc, mempool and ring
libraries and that eal does not have proper DT_NEEDED entries, we work
around it by forcing linking against mentioned libraries by preceding
them with --no-as-needed flag when building shared libraries.

This patch also does:
 - Set --start-group/--end-group and --whole-archive/--no-whole-archive
   flags only when linking against static DPDK libs.
 - Set --as-needed for all libraries but eal, malloc, mempool and
   ring when linking against shared DPDK libs.
 - Link against EXECENV_LIBS always with --as-needed flag.

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 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	[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 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 2/8] core: create new librte_core Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 3/8] mk: new corelib makefile Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 4/8] lib: update DEPDIRS variable Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 5/8] lib: set LDLIBS for each library Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 6/8] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 7/8] mk: update LDLIBS for app building Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy
2015-01-29 16:38 ` [dpdk-dev] [PATCH 0/8] Improve build process Neil Horman
2015-01-29 17:02   ` Thomas Monjalon
2015-01-29 17:04   ` Gonzalez Monroy, Sergio
2015-01-29 19:45     ` Neil Horman
2015-01-30 13:39       ` Gonzalez Monroy, Sergio
2015-01-30 14:05         ` Neil Horman
2015-01-30 17:38           ` Gonzalez Monroy, Sergio
2015-01-30 18:12             ` Neil Horman
2015-02-11 11:11               ` Gonzalez Monroy, Sergio
2015-02-12  5:41                 ` Neil Horman
2015-02-12  9:17                   ` Gonzalez Monroy, Sergio
2015-02-12 12:16                     ` Neil Horman
2015-02-12  9:22                 ` Panu Matilainen
2015-02-12 10:03                   ` Gonzalez Monroy, Sergio
2015-02-12 12:23                     ` Neil Horman
2015-02-12 14:07                       ` Panu Matilainen
2015-02-12 15:52                         ` Neil Horman
2015-02-13 10:14                           ` Panu Matilainen
2015-02-13 11:08                             ` Gonzalez Monroy, Sergio
2015-02-13 12:51                               ` Neil Horman
2015-02-20 14:31                                 ` Gonzalez Monroy, Sergio
2015-02-22 23:37                                   ` Neil Horman
2015-02-23 10:25                                     ` Gonzalez Monroy, Sergio
2015-02-23 13:52                                       ` Neil Horman
2015-02-23 14:58                                         ` Gonzalez Monroy, Sergio
2015-02-23 18:23                                           ` Neil Horman
2015-02-24 13:24                                             ` Gonzalez Monroy, Sergio
2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
2015-03-13 10:49     ` Kavanagh, Mark B
2015-03-13 11:19       ` Gonzalez Monroy, Sergio
2015-03-13 11:34         ` Kavanagh, Mark B
2015-03-13 11:48           ` Gonzalez Monroy, Sergio
2015-03-13 13:16             ` Kavanagh, Mark B
2015-03-13 14:11               ` Gonzalez Monroy, Sergio
2015-03-13 13:17             ` Neil Horman
2015-03-13 14:12               ` Stefan Puiu
2015-03-13 15:18                 ` Neil Horman
2015-03-13 15:28                   ` Gonzalez Monroy, Sergio
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
2015-03-18 12:59       ` Thomas Monjalon
2015-03-18 15:30         ` Stefan Puiu
2015-03-18 15:52           ` Gonzalez Monroy, Sergio
2015-03-18 16:48           ` Neil Horman
2015-03-26  8:52         ` Gonzalez Monroy, Sergio
2015-03-26 10:30           ` Neil Horman
2015-03-18 16:41       ` Neil Horman
2015-03-12 16:27   ` [dpdk-dev] [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy
2015-03-12 16:28   ` [dpdk-dev] [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-03-12 16:28   ` [dpdk-dev] [PATCH v2 4/4] mk: update LDLIBS for app building Sergio Gonzalez Monroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).