[dpdk-dev] [PATCH v3 0/5] Enhance build process

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

* [dpdk-dev] [PATCH v3 0/5] Enhance build process
@ 2015-04-08 15:07 Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
                   ` (4 more replies)
  0 siblings, 5 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
  To: dev

This patch series has the following goals:
 - Remove config option to build a combined library to simplify maintenance.
 - Add makefile to always generate linker script that behaves like 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.

v3:
 - keep CONFIG_RTE_LIBNAME config option.
 - add makefile to always generate a linker script that behaves like a
   combined library.
 - rebase patch

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 (5):
  mk: remove combined library and related options
  mk: always generate combined lib linker script
  lib: set LDLIBS for each library
  mk: use LDLIBS when linking shared libraries
  mk: update LDLIBS for app building

 config/common_bsdapp                 |   3 +-
 config/common_linuxapp               |   3 +-
 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_eal/bsdapp/eal/Makefile   |   2 +
 lib/librte_eal/linuxapp/eal/Makefile |   2 +
 lib/librte_ether/Makefile            |   5 +-
 lib/librte_hash/Makefile             |   2 +
 lib/librte_ip_frag/Makefile          |   3 ++
 lib/librte_ivshmem/Makefile          |   2 +
 lib/librte_jobstats/Makefile         |   2 +
 lib/librte_kni/Makefile              |   2 +
 lib/librte_kvargs/Makefile           |   2 +
 lib/librte_lpm/Makefile              |   2 +
 lib/librte_malloc/Makefile           |   2 +
 lib/librte_mbuf/Makefile             |   2 +
 lib/librte_mempool/Makefile          |   2 +
 lib/librte_meter/Makefile            |   2 +
 lib/librte_pipeline/Makefile         |   2 +
 lib/librte_pmd_af_packet/Makefile    |   2 +
 lib/librte_pmd_bond/Makefile         |   6 +++
 lib/librte_pmd_e1000/Makefile        |   2 +
 lib/librte_pmd_enic/Makefile         |   3 ++
 lib/librte_pmd_fm10k/Makefile        |   2 +
 lib/librte_pmd_i40e/Makefile         |   2 +
 lib/librte_pmd_ixgbe/Makefile        |   2 +
 lib/librte_pmd_mlx4/Makefile         |   2 +
 lib/librte_pmd_null/Makefile         |   2 +
 lib/librte_pmd_pcap/Makefile         |   2 +
 lib/librte_pmd_ring/Makefile         |   4 +-
 lib/librte_pmd_virtio/Makefile       |   2 +
 lib/librte_pmd_vmxnet3/Makefile      |   2 +
 lib/librte_pmd_xenvirt/Makefile      |   3 ++
 lib/librte_port/Makefile             |   4 ++
 lib/librte_power/Makefile            |   2 +
 lib/librte_reorder/Makefile          |   2 +
 lib/librte_ring/Makefile             |   2 +
 lib/librte_sched/Makefile            |   2 +
 lib/librte_table/Makefile            |   4 ++
 lib/librte_timer/Makefile            |   2 +
 lib/librte_vhost/Makefile            |   7 ++-
 mk/rte.app.mk                        |  60 ++++++++++-----------
 mk/rte.combinedlib.mk                |  89 ++++++++++++++++++++++++++++++
 mk/rte.lib.mk                        |  50 ++++-------------
 mk/rte.sdkbuild.mk                   |   4 +-
 mk/rte.sharelib.mk                   | 101 -----------------------------------
 mk/rte.vars.mk                       |   4 --
 50 files changed, 229 insertions(+), 189 deletions(-)
 create mode 100644 mk/rte.combinedlib.mk
 delete mode 100644 mk/rte.sharelib.mk

-- 
1.9.3

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

* [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
  2015-04-08 18:26   ` Stephen Hemminger
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script Sergio Gonzalez Monroy
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
  To: dev

Currently, the target/rules to build combined libraries is different
than the one to build individual libraries.

By removing the combined library option as a build configuration option
we simplify the build pocess by having a single point for linking/archiving
libraries in DPDK.

This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
removes the makefiles associated with building a combined library.

The CONFIG_RTE_LIBNAME config option is kept as it will be use to
always generate a linker script that acts as a single combined library.

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 config/common_bsdapp   |   3 +-
 config/common_linuxapp |   3 +-
 lib/Makefile           |   1 -
 mk/rte.app.mk          |  12 ------
 mk/rte.lib.mk          |  35 -----------------
 mk/rte.sdkbuild.mk     |   3 --
 mk/rte.sharelib.mk     | 101 -------------------------------------------------
 mk/rte.vars.mk         |   4 --
 8 files changed, 2 insertions(+), 160 deletions(-)
 delete mode 100644 mk/rte.sharelib.mk

diff --git a/config/common_bsdapp b/config/common_bsdapp
index a8ba484..ab6be97 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_BUILD_SHARED_LIB=n
 
 #
-# Combine to one single library
+# Combined library name
 #
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
 CONFIG_RTE_LIBNAME=intel_dpdk
 
 #
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0b25f34..1ae4304 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_BUILD_SHARED_LIB=n
 
 #
-# Combine to one single library
+# Combined library name
 #
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
 CONFIG_RTE_LIBNAME="intel_dpdk"
 
 #
diff --git a/lib/Makefile b/lib/Makefile
index d94355d..c34cf2f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -77,5 +77,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
 DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
 endif
 
-include $(RTE_SDK)/mk/rte.sharelib.mk
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 56886dc..e8630b6 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -61,12 +61,6 @@ ifeq ($(NO_AUTOLIBS),)
 
 LDLIBS += --whole-archive
 
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-LDLIBS += -l$(RTE_LIBNAME)
-endif
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
 ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
 LDLIBS += -lrte_distributor
 endif
@@ -137,8 +131,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
 LDLIBS += -lrte_vhost
 endif
 
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
 ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
 LDLIBS += -lpcap
 endif
@@ -153,8 +145,6 @@ endif
 
 LDLIBS += --start-group
 
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
 ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
 LDLIBS += -lrte_kvargs
 endif
@@ -253,8 +243,6 @@ endif
 
 endif # plugins
 
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
 LDLIBS += $(EXECENV_LDLIBS)
 
 LDLIBS += --end-group
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 0d7482d..d96101a 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -87,24 +87,6 @@ O_TO_S_DO = @set -e; \
 	$(O_TO_S) && \
 	echo $(O_TO_S_CMD) > $(call exe2cmd,$(@))
 
-ifeq ($(RTE_BUILD_SHARED_LIB),n)
-O_TO_C = $(AR) crus $(LIB_ONE) $(OBJS-y)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  AR_C $(@)")
-O_TO_C_DO = @set -e; \
-	$(lib_dir) \
-	$(copy_obj)
-else
-O_TO_C = $(LD) -shared $(OBJS-y) -o $(LIB_ONE)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  LD_C $(@)")
-O_TO_C_DO = @set -e; \
-	$(lib_dir) \
-	$(copy_obj)
-endif
-
-copy_obj = cp -f $(OBJS-y) $(RTE_OUTPUT)/build/lib;
-lib_dir = [ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib;
 -include .$(LIB).cmd
 
 #
@@ -129,15 +111,6 @@ endif
 		$(depfile_missing),\
 		$(depfile_newer)),\
 		$(O_TO_S_DO))
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-	$(if $(or \
-        $(file_missing),\
-        $(call cmdline_changed,$(O_TO_C_STR)),\
-        $(depfile_missing),\
-        $(depfile_newer)),\
-        $(O_TO_C_DO))
-endif
 else
 $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
 	@[ -d $(dir $@) ] || mkdir -p $(dir $@)
@@ -153,14 +126,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
 	    $(depfile_missing),\
 	    $(depfile_newer)),\
 	    $(O_TO_A_DO))
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-	$(if $(or \
-        $(file_missing),\
-        $(call cmdline_changed,$(O_TO_C_STR)),\
-        $(depfile_missing),\
-        $(depfile_newer)),\
-        $(O_TO_C_DO))
-endif
 endif
 
 #
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 3154457..2b24e74 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,9 +93,6 @@ $(ROOTDIRS-y):
 	@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
 	@echo "== Build $@"
 	$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
-	@if [ $@ = lib -a $(RTE_BUILD_COMBINE_LIBS) = y ]; then \
-		$(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
-	fi
 
 %_clean:
 	@echo "== Clean $*"
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
deleted file mode 100644
index de53558..0000000
--- a/mk/rte.sharelib.mk
+++ /dev/null
@@ -1,101 +0,0 @@
-#   BSD LICENSE
-#
-#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-#   All rights reserved.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-#     * Redistributions of source code must retain the above copyright
-#       notice, this list of conditions and the following disclaimer.
-#     * Redistributions in binary form must reproduce the above copyright
-#       notice, this list of conditions and the following disclaimer in
-#       the documentation and/or other materials provided with the
-#       distribution.
-#     * Neither the name of Intel Corporation nor the names of its
-#       contributors may be used to endorse or promote products derived
-#       from this software without specific prior written permission.
-#
-#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-include $(RTE_SDK)/mk/internal/rte.build-pre.mk
-
-# VPATH contains at least SRCDIR
-VPATH += $(SRCDIR)
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(RTE_BUILD_SHARED_LIB),y)
-LIB_ONE := lib$(RTE_LIBNAME).so
-else
-LIB_ONE := lib$(RTE_LIBNAME).a
-endif
-endif
-
-.PHONY:sharelib
-sharelib: $(LIB_ONE) FORCE
-
-OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)
-
-ifeq ($(LINK_USING_CC),1)
-# Override the definition of LD here, since we're linking with CC
-LD := $(CC) $(CPU_CFLAGS)
-O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
-	-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
-	-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-endif
-
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
-O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)","  LD $(@)")
-O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
-O_TO_S_DO = @set -e; \
-    echo $(O_TO_S_DISP); \
-    $(O_TO_S)
-
-O_TO_A =  $(AR) crus $(RTE_OUTPUT)/lib/$(LIB_ONE) $(OBJS)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
-O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)","  LD $(@)")
-O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
-O_TO_A_DO = @set -e; \
-    echo $(O_TO_A_DISP); \
-    $(O_TO_A)
-#
-# Archive objects to share library
-#
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(RTE_BUILD_SHARED_LIB),y)
-$(LIB_ONE): FORCE
-	@[ -d $(dir $@) ] || mkdir -p $(dir $@)
-	$(O_TO_S_DO)
-else
-$(LIB_ONE): FORCE
-	@[ -d $(dir $@) ] || mkdir -p $(dir $@)
-	$(O_TO_A_DO)
-endif
-endif
-
-#
-# Clean all generated files
-#
-.PHONY: clean
-clean: _postclean
-
-.PHONY: doclean
-doclean:
-	$(Q)rm -rf $(LIB_ONE)
-
-.PHONY: FORCE
-FORCE:
diff --git a/mk/rte.vars.mk b/mk/rte.vars.mk
index d2f01b6..fd06175 100644
--- a/mk/rte.vars.mk
+++ b/mk/rte.vars.mk
@@ -67,10 +67,6 @@ ifneq ($(BUILDING_RTE_SDK),)
   ifeq ($(RTE_BUILD_SHARED_LIB),)
     RTE_BUILD_SHARED_LIB := n
   endif
-  RTE_BUILD_COMBINE_LIBS := $(CONFIG_RTE_BUILD_COMBINE_LIBS:"%"=%)
-  ifeq ($(RTE_BUILD_COMBINE_LIBS),)
-    RTE_BUILD_COMBINE_LIBS := n
-  endif
 endif
 
 RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
-- 
1.9.3

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

* [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script
  2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library Sergio Gonzalez Monroy
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
  To: dev

After the patch, building DPDK will always generate a linker script
(name use is based on CONFIG_RTE_LIBNAME config option) that behaves
as a combined library when linking against it.

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 mk/rte.combinedlib.mk | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++
 mk/rte.sdkbuild.mk    |  3 ++
 2 files changed, 92 insertions(+)
 create mode 100644 mk/rte.combinedlib.mk

diff --git a/mk/rte.combinedlib.mk b/mk/rte.combinedlib.mk
new file mode 100644
index 0000000..46d6ee9
--- /dev/null
+++ b/mk/rte.combinedlib.mk
@@ -0,0 +1,89 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+#     * Redistributions of source code must retain the above copyright
+#       notice, this list of conditions and the following disclaimer.
+#     * Redistributions in binary form must reproduce the above copyright
+#       notice, this list of conditions and the following disclaimer in
+#       the documentation and/or other materials provided with the
+#       distribution.
+#     * Neither the name of Intel Corporation nor the names of its
+#       contributors may be used to endorse or promote products derived
+#       from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+default: all
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+EXT:=.so
+else
+EXT:=.a
+endif
+
+COMBINEDLIB := lib$(RTE_LIBNAME).so
+
+CORE_LIBS := librte_eal librte_mempool librte_malloc librte_ring
+CORE_LIBS := $(addsuffix $(EXT),$(CORE_LIBS))
+
+ALL_LIBS := $(wildcard $(RTE_OUTPUT)/lib/*$(EXT))
+ALL_LIBS := $(filter-out $(CORE_LIBS),$(notdir $(ALL_LIBS)))
+
+# If we change the combined lib name and we build dpdk without doing
+# 'make uninstall', the previous linker script would be present in the dir.
+filter_type = $(if $(shell file $(lib) | grep "ASCII text"),,$(lib))
+LIBS := $(foreach lib,$(ALL_LIBS),$(filter_type))
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT = INPUT (
+else
+LDSCRIPT = GROUP (
+endif
+
+LDSCRIPT += $(CORE_LIBS)
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT += AS_NEEDED (
+endif
+
+# For shared libs we do not care if we link against PMDs here,
+# they will be ignored (ie. after AS_NEEDED) as there are no direct
+# references to them
+LDSCRIPT += $(LIBS)
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDSCRIPT += )
+endif
+
+LDSCRIPT += )
+
+all: FORCE
+	$(Q)echo "$(LDSCRIPT)" > $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+#
+# Clean all generated files
+#
+.PHONY: clean
+clean:
+	$(Q)rm -f $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+.PHONY: FORCE
+FORCE:
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 2b24e74..625e0c4 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,6 +93,9 @@ $(ROOTDIRS-y):
 	@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
 	@echo "== Build $@"
 	$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
+	@if [ $@ = lib ]; then \
+		$(MAKE) -f $(RTE_SDK)/mk/rte.combinedlib.mk; \
+	fi
 
 %_clean:
 	@echo "== Clean $*"
-- 
1.9.3

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

* [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library
  2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building Sergio Gonzalez Monroy
  4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
  To: dev

When creating shared libraries, each library will be linked against
their dependant libraries, specified by the new LDLIBS variable.

Given the circular dependencies between eal, malloc, mempool and ring,
we work around it by not linking eal against its dependent libraries.
Therefore, eal will not have proper DT_NEEDED entries (ie. no DT_NEEDED
entries for librte_malloc and librte_mempool) and we will have to force
link against them by preceding such libraries with --no-as-needed flag.

This patch sets LDLIBS variable for each library and updates DEPDIRS
of some libraries.

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 lib/librte_acl/Makefile              | 2 ++
 lib/librte_cfgfile/Makefile          | 2 ++
 lib/librte_cmdline/Makefile          | 2 ++
 lib/librte_distributor/Makefile      | 2 ++
 lib/librte_eal/bsdapp/eal/Makefile   | 2 ++
 lib/librte_eal/linuxapp/eal/Makefile | 2 ++
 lib/librte_ether/Makefile            | 5 ++++-
 lib/librte_hash/Makefile             | 2 ++
 lib/librte_ip_frag/Makefile          | 3 +++
 lib/librte_ivshmem/Makefile          | 2 ++
 lib/librte_jobstats/Makefile         | 2 ++
 lib/librte_kni/Makefile              | 2 ++
 lib/librte_kvargs/Makefile           | 2 ++
 lib/librte_lpm/Makefile              | 2 ++
 lib/librte_malloc/Makefile           | 2 ++
 lib/librte_mbuf/Makefile             | 2 ++
 lib/librte_mempool/Makefile          | 2 ++
 lib/librte_meter/Makefile            | 2 ++
 lib/librte_pipeline/Makefile         | 2 ++
 lib/librte_pmd_af_packet/Makefile    | 2 ++
 lib/librte_pmd_bond/Makefile         | 6 ++++++
 lib/librte_pmd_e1000/Makefile        | 2 ++
 lib/librte_pmd_enic/Makefile         | 3 +++
 lib/librte_pmd_fm10k/Makefile        | 2 ++
 lib/librte_pmd_i40e/Makefile         | 2 ++
 lib/librte_pmd_ixgbe/Makefile        | 2 ++
 lib/librte_pmd_mlx4/Makefile         | 2 ++
 lib/librte_pmd_null/Makefile         | 2 ++
 lib/librte_pmd_pcap/Makefile         | 2 ++
 lib/librte_pmd_ring/Makefile         | 4 +++-
 lib/librte_pmd_virtio/Makefile       | 2 ++
 lib/librte_pmd_vmxnet3/Makefile      | 2 ++
 lib/librte_pmd_xenvirt/Makefile      | 3 +++
 lib/librte_port/Makefile             | 4 ++++
 lib/librte_power/Makefile            | 2 ++
 lib/librte_reorder/Makefile          | 2 ++
 lib/librte_ring/Makefile             | 2 ++
 lib/librte_sched/Makefile            | 2 ++
 lib/librte_table/Makefile            | 4 ++++
 lib/librte_timer/Makefile            | 2 ++
 lib/librte_vhost/Makefile            | 7 +++++--
 41 files changed, 99 insertions(+), 4 deletions(-)

diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 68dc248..00f5e33 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_acl_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c
 
diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index 032c240..babe7d1 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_cfgfile_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile
index 719dff6..0f7935f 100644
--- a/lib/librte_cmdline/Makefile
+++ b/lib/librte_cmdline/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_cmdline_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := cmdline.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_cirbuf.c
diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 4c9af17..b275491 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_distributor_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mbuf
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c
 
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index 2357cfa..8d7a6fc 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -46,6 +46,8 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_ring
 CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_pcap
 CFLAGS += $(WERROR_FLAGS) -O3
 
+LDLIBS += -lrt
+
 EXPORT_MAP := rte_eal_version.map
 
 LIBABIVER := 1
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 01f7b70..c351a38 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -53,6 +53,8 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_af_packet
 CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
 CFLAGS += $(WERROR_FLAGS) -O3
 
+LDLIBS += -lrt
+
 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) := eal.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_hugepage_info.c
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index c0e5768..a1059d7 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_ether_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_ring -lrte_malloc
+
 SRCS-y += rte_ethdev.c
 
 #
@@ -53,6 +55,7 @@ SYMLINK-y-include += rte_ethdev.h
 SYMLINK-y-include += rte_eth_ctrl.h
 
 # this lib depends upon:
-DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring lib/librte_mbuf
+DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring
+DEPDIRS-y += lib/librte_mbuf lib/librte_malloc
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
index 3696cb1..bc9bfc7 100644
--- a/lib/librte_hash/Makefile
+++ b/lib/librte_hash/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_hash_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_HASH) := rte_hash.c
 SRCS-$(CONFIG_RTE_LIBRTE_HASH) += rte_fbk_hash.c
diff --git a/lib/librte_ip_frag/Makefile b/lib/librte_ip_frag/Makefile
index 9d06780..ee72ab4 100644
--- a/lib/librte_ip_frag/Makefile
+++ b/lib/librte_ip_frag/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_ipfrag_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
 #source files
 SRCS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += rte_ipv4_fragmentation.c
 SRCS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += rte_ipv6_fragmentation.c
@@ -55,5 +57,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_IP_FRAG)-include += rte_ip_frag.h
 
 # this library depends on rte_ether
 DEPDIRS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += lib/librte_mempool lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += lib/librte_malloc lib/librte_mbuf
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ivshmem/Makefile b/lib/librte_ivshmem/Makefile
index 16defdb..fab6f5f 100644
--- a/lib/librte_ivshmem/Makefile
+++ b/lib/librte_ivshmem/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_ivshmem_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_mempool
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_IVSHMEM) := rte_ivshmem.c
 
diff --git a/lib/librte_jobstats/Makefile b/lib/librte_jobstats/Makefile
index 136a448..04589d4 100644
--- a/lib/librte_jobstats/Makefile
+++ b/lib/librte_jobstats/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_jobstats_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_JOBSTATS) := rte_jobstats.c
 
diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile
index 7107832..504ecf7 100644
--- a/lib/librte_kni/Makefile
+++ b/lib/librte_kni/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_kni_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_KNI) := rte_kni.c
 
diff --git a/lib/librte_kvargs/Makefile b/lib/librte_kvargs/Makefile
index 87b09f2..173e1ac 100644
--- a/lib/librte_kvargs/Makefile
+++ b/lib/librte_kvargs/Makefile
@@ -42,6 +42,8 @@ EXPORT_MAP := rte_kvargs_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) := rte_kvargs.c
 
diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile
index 35e6389..125d52e 100644
--- a/lib/librte_lpm/Makefile
+++ b/lib/librte_lpm/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_lpm_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c
 
diff --git a/lib/librte_malloc/Makefile b/lib/librte_malloc/Makefile
index 947e41c..3e7348f 100644
--- a/lib/librte_malloc/Makefile
+++ b/lib/librte_malloc/Makefile
@@ -40,6 +40,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
 
 EXPORT_MAP := rte_malloc_version.map
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_MALLOC) := rte_malloc.c malloc_elem.c malloc_heap.c
 
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index 080f3cf..d819891 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_mbuf_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c
 
diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index 940d1f7..8ebebb6 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_mempool_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc -lrte_ring
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool.c
 ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile
index 8765881..d5eafb0 100644
--- a/lib/librte_meter/Makefile
+++ b/lib/librte_meter/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_meter_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile
index 15e406b..16de0a3 100644
--- a/lib/librte_pipeline/Makefile
+++ b/lib/librte_pipeline/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_pipeline_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_af_packet/Makefile b/lib/librte_pmd_af_packet/Makefile
index f0bf537..14a9957 100644
--- a/lib/librte_pmd_af_packet/Makefile
+++ b/lib/librte_pmd_af_packet/Makefile
@@ -45,6 +45,8 @@ LIBABIVER := 1
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
 
+LDLIBS += -lrte_eal -lrte_malloc -lethdev -lrte_kvargs
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_bond/Makefile b/lib/librte_pmd_bond/Makefile
index 83ccce3..d046489 100644
--- a/lib/librte_pmd_bond/Makefile
+++ b/lib/librte_pmd_bond/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_eth_bond_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_ring -lrte_mempool -lrte_malloc
+LDLIBS += -lethdev -lrte_kvargs -lrte_cmdline
+
 #
 # all source are stored in SRCS-y
 #
@@ -59,10 +62,13 @@ SYMLINK-y-include += rte_eth_bond.h
 SYMLINK-y-include += rte_eth_bond_8023ad.h
 
 # this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_ring
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_mempool
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_mbuf
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_ether
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_malloc
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_eal
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_kvargs
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_cmdline
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_pmd_e1000/Makefile b/lib/librte_pmd_e1000/Makefile
index 8c8fed8..5af6b6a 100644
--- a/lib/librte_pmd_e1000/Makefile
+++ b/lib/librte_pmd_e1000/Makefile
@@ -65,6 +65,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
 
 VPATH += $(RTE_SDK)/lib/librte_pmd_e1000/e1000
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
index 251a898..e0100b2 100644
--- a/lib/librte_pmd_enic/Makefile
+++ b/lib/librte_pmd_enic/Makefile
@@ -48,6 +48,9 @@ CFLAGS += $(WERROR_FLAGS) -Wno-strict-aliasing
 
 VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc
+LDLIBS += -lethdev -lrte_hash
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_fm10k/Makefile b/lib/librte_pmd_fm10k/Makefile
index 7516d37..9ee0d48 100644
--- a/lib/librte_pmd_fm10k/Makefile
+++ b/lib/librte_pmd_fm10k/Makefile
@@ -81,6 +81,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
 
 VPATH += $(RTE_SDK)/lib/librte_pmd_fm10k/base
 
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile
index 64bab16..fa0d858 100644
--- a/lib/librte_pmd_i40e/Makefile
+++ b/lib/librte_pmd_i40e/Makefile
@@ -80,6 +80,8 @@ $(foreach obj, $(OBJS_BASE_DRIVER), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
 
 VPATH += $(RTE_SDK)/lib/librte_pmd_i40e/i40e
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile
index ae36202..d96edf2 100644
--- a/lib/librte_pmd_ixgbe/Makefile
+++ b/lib/librte_pmd_ixgbe/Makefile
@@ -91,6 +91,8 @@ $(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))
 
 VPATH += $(RTE_SDK)/lib/librte_pmd_ixgbe/ixgbe
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_mlx4/Makefile b/lib/librte_pmd_mlx4/Makefile
index 97b364a..a367748 100644
--- a/lib/librte_pmd_mlx4/Makefile
+++ b/lib/librte_pmd_mlx4/Makefile
@@ -58,6 +58,8 @@ CFLAGS += -Wno-error=cast-qual
 EXPORT_MAP := rte_pmd_mlx4_version.map
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_malloc -lethdev -libverbs
+
 # DEBUG which is usually provided on the command-line may enable
 # CONFIG_RTE_LIBRTE_MLX4_DEBUG.
 ifeq ($(DEBUG),1)
diff --git a/lib/librte_pmd_null/Makefile b/lib/librte_pmd_null/Makefile
index 6472015..c9bf1fd 100644
--- a/lib/librte_pmd_null/Makefile
+++ b/lib/librte_pmd_null/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_pmd_null_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc -lethdev -lrte_kvargs
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_pcap/Makefile b/lib/librte_pmd_pcap/Makefile
index 0775dbc..2717978 100644
--- a/lib/librte_pmd_pcap/Makefile
+++ b/lib/librte_pmd_pcap/Makefile
@@ -44,6 +44,8 @@ EXPORT_MAP := rte_pmd_pcap_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_mbuf -lrte_malloc -lethdev -lrte_kvargs -lpcap
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_ring/Makefile b/lib/librte_pmd_ring/Makefile
index e442d0b..33a4fb3 100644
--- a/lib/librte_pmd_ring/Makefile
+++ b/lib/librte_pmd_ring/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_eth_ring_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_ring -lrte_malloc -lethdev -lrte_kvargs
+
 #
 # all source are stored in SRCS-y
 #
@@ -56,6 +58,6 @@ SYMLINK-y-include += rte_eth_ring.h
 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_eal lib/librte_ring
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_mbuf lib/librte_ether
-DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_kvargs
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += lib/librte_kvargs lib/librte_malloc
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_pmd_virtio/Makefile b/lib/librte_pmd_virtio/Makefile
index 793067f..25f7928 100644
--- a/lib/librte_pmd_virtio/Makefile
+++ b/lib/librte_pmd_virtio/Makefile
@@ -43,6 +43,8 @@ EXPORT_MAP := rte_pmd_virtio_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc -lethdev
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile
index fc616c4..35c0c90 100644
--- a/lib/librte_pmd_vmxnet3/Makefile
+++ b/lib/librte_pmd_vmxnet3/Makefile
@@ -70,6 +70,8 @@ EXPORT_MAP := rte_pmd_vmxnet3_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc -lethdev
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_pmd_xenvirt/Makefile b/lib/librte_pmd_xenvirt/Makefile
index f0c796c..df39a6e 100644
--- a/lib/librte_pmd_xenvirt/Makefile
+++ b/lib/librte_pmd_xenvirt/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_eth_xenvirt_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc
+LDLIBS += -lethdev -rte_cmdline -xenstore
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_port/Makefile b/lib/librte_port/Makefile
index de960fc..595a682 100644
--- a/lib/librte_port/Makefile
+++ b/lib/librte_port/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_port_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_malloc
+LDLIBS += -lethdev -lrte_ip_frag -lrte_sched
+
 #
 # all source are stored in SRCS-y
 #
@@ -73,5 +76,6 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_mempool
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_malloc
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ether
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_ip_frag
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PORT) += lib/librte_sched
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_power/Makefile b/lib/librte_power/Makefile
index cee95cd..ec9107e 100644
--- a/lib/librte_power/Makefile
+++ b/lib/librte_power/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_power_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_POWER) := rte_power.c rte_power_acpi_cpufreq.c
 SRCS-$(CONFIG_RTE_LIBRTE_POWER) += rte_power_kvm_vm.c guest_channel.c
diff --git a/lib/librte_reorder/Makefile b/lib/librte_reorder/Makefile
index 0c01de1..2c8f774 100644
--- a/lib/librte_reorder/Makefile
+++ b/lib/librte_reorder/Makefile
@@ -41,6 +41,8 @@ EXPORT_MAP := rte_reorder_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_REORDER) := rte_reorder.c
 
diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
index 84ad3d3..1ff6cb6 100644
--- a/lib/librte_ring/Makefile
+++ b/lib/librte_ring/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_ring_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
 
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index b1cb285..a3ac216 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -45,6 +45,8 @@ EXPORT_MAP := rte_sched_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_malloc
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile
index 0d8394c..2254d52 100644
--- a/lib/librte_table/Makefile
+++ b/lib/librte_table/Makefile
@@ -43,6 +43,9 @@ EXPORT_MAP := rte_table_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_malloc
+LDLIBS += -lrte_port -lrte_lpm -lrte_hash
+
 #
 # all source are stored in SRCS-y
 #
@@ -80,6 +83,7 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_port
 DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_lpm
 ifeq ($(CONFIG_RTE_LIBRTE_ACL),y)
 DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_acl
+LDLIBS += -lrte_acl
 endif
 DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_hash
 
diff --git a/lib/librte_timer/Makefile b/lib/librte_timer/Makefile
index 2aabef8..859fa1a 100644
--- a/lib/librte_timer/Makefile
+++ b/lib/librte_timer/Makefile
@@ -40,6 +40,8 @@ EXPORT_MAP := rte_timer_version.map
 
 LIBABIVER := 1
 
+LDLIBS += -lrte_eal
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_TIMER) := rte_timer.c
 
diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
index a8645a6..ac486ce 100644
--- a/lib/librte_vhost/Makefile
+++ b/lib/librte_vhost/Makefile
@@ -39,11 +39,14 @@ EXPORT_MAP := rte_vhost_version.map
 LIBABIVER := 1
 
 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64
+
+LDLIBS += -lrte_eal -lrte_mbuf -lethdev
+
 ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),y)
 CFLAGS += -I vhost_user
 else
-CFLAGS += -I vhost_cuse -lfuse
-LDFLAGS += -lfuse
+CFLAGS += -I vhost_cuse
+LDLIBS += -lfuse
 endif
 
 # all source are stored in SRCS-y
-- 
1.9.3

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

* [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries
  2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
                   ` (2 preceding siblings ...)
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building Sergio Gonzalez Monroy
  4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
  To: dev

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

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

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

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

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

* [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building
  2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
                   ` (3 preceding siblings ...)
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
@ 2015-04-08 15:07 ` Sergio Gonzalez Monroy
  4 siblings, 0 replies; 18+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-04-08 15:07 UTC (permalink / raw)
  To: dev

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

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

Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
 mk/rte.app.mk | 54 ++++++++++++++++++++++++++++++------------------------
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index e8630b6..2d6b2ca 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -59,7 +59,30 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib
 #
 ifeq ($(NO_AUTOLIBS),)
 
-LDLIBS += --whole-archive
+LDLIBS += --no-as-needed
+ifneq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDLIBS += --start-group
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_EAL),y)
+LDLIBS += -lrte_eal
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y)
+LDLIBS += -lrte_malloc
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y)
+LDLIBS += -lrte_mempool
+endif
+
+ifeq ($(CONFIG_RTE_LIBRTE_RING),y)
+LDLIBS += -lrte_ring
+endif
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+LDLIBS += --as-needed
+endif
 
 ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
 LDLIBS += -lrte_distributor
@@ -127,7 +150,7 @@ LDLIBS += -lm
 LDLIBS += -lrt
 endif
 
-ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
+ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
 LDLIBS += -lrte_vhost
 endif
 
@@ -143,8 +166,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_MLX4_PMD),y)
 LDLIBS += -libverbs
 endif
 
-LDLIBS += --start-group
-
 ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
 LDLIBS += -lrte_kvargs
 endif
@@ -161,22 +182,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_ETHER),y)
 LDLIBS += -lethdev
 endif
 
-ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y)
-LDLIBS += -lrte_malloc
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y)
-LDLIBS += -lrte_mempool
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_RING),y)
-LDLIBS += -lrte_ring
-endif
-
-ifeq ($(CONFIG_RTE_LIBRTE_EAL),y)
-LDLIBS += -lrte_eal
-endif
-
 ifeq ($(CONFIG_RTE_LIBRTE_CMDLINE),y)
 LDLIBS += -lrte_cmdline
 endif
@@ -196,6 +201,7 @@ endif
 
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
 # plugins (link only if static libraries)
+LDLIBS += --whole-archive
 
 ifeq ($(CONFIG_RTE_LIBRTE_VMXNET3_PMD),y)
 LDLIBS += -lrte_pmd_vmxnet3_uio
@@ -241,14 +247,14 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_AF_PACKET),y)
 LDLIBS += -lrte_pmd_af_packet
 endif
 
+LDLIBS += --no-whole-archive
+LDLIBS += --end-group
+LDLIBS += --as-needed
+
 endif # plugins
 
 LDLIBS += $(EXECENV_LDLIBS)
 
-LDLIBS += --end-group
-
-LDLIBS += --no-whole-archive
-
 endif # ifeq ($(NO_AUTOLIBS),)
 
 LDLIBS += $(CPU_LDLIBS)
-- 
1.9.3

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
@ 2015-04-08 18:26   ` Stephen Hemminger
  2015-04-09  8:33     ` Gonzalez Monroy, Sergio
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Hemminger @ 2015-04-08 18:26 UTC (permalink / raw)
  To: Sergio Gonzalez Monroy; +Cc: dev

On Wed,  8 Apr 2015 16:07:21 +0100
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:

> Currently, the target/rules to build combined libraries is different
> than the one to build individual libraries.
> 
> By removing the combined library option as a build configuration option
> we simplify the build pocess by having a single point for linking/archiving
> libraries in DPDK.
> 
> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> removes the makefiles associated with building a combined library.
> 
> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> always generate a linker script that acts as a single combined library.
> 
> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>

No. We use combined library and it greatly simplfies the application
linking process.

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-08 18:26   ` Stephen Hemminger
@ 2015-04-09  8:33     ` Gonzalez Monroy, Sergio
  2015-04-09  9:06       ` Avi Kivity
  0 siblings, 1 reply; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-09  8:33 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev

On 08/04/2015 19:26, Stephen Hemminger wrote:
> On Wed,  8 Apr 2015 16:07:21 +0100
> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>
>> Currently, the target/rules to build combined libraries is different
>> than the one to build individual libraries.
>>
>> By removing the combined library option as a build configuration option
>> we simplify the build pocess by having a single point for linking/archiving
>> libraries in DPDK.
>>
>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>> removes the makefiles associated with building a combined library.
>>
>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>> always generate a linker script that acts as a single combined library.
>>
>> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> No. We use combined library and it greatly simplfies the application
> linking process.
>
After all the opposition this patch had in v2, I did explain the current 
issues
(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this 
was the agreed solution.

As I mention in the cover letter (also see patch 2/5), building DPDK 
(after applying this patch series) will always generate a very simple 
linker script that behaves as a combined library.
I encourage you to apply this patch series and try to build your app 
(which links against combined lib).
Your app should build without problem unless I messed up somewhere and 
it needs fixing.

Sergio

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09  8:33     ` Gonzalez Monroy, Sergio
@ 2015-04-09  9:06       ` Avi Kivity
  2015-04-09  9:42         ` Gonzalez Monroy, Sergio
  2015-04-09 11:19         ` Neil Horman
  0 siblings, 2 replies; 18+ messages in thread
From: Avi Kivity @ 2015-04-09  9:06 UTC (permalink / raw)
  To: Gonzalez Monroy, Sergio, Stephen Hemminger; +Cc: dev



On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> On 08/04/2015 19:26, Stephen Hemminger wrote:
>> On Wed,  8 Apr 2015 16:07:21 +0100
>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>
>>> Currently, the target/rules to build combined libraries is different
>>> than the one to build individual libraries.
>>>
>>> By removing the combined library option as a build configuration option
>>> we simplify the build pocess by having a single point for 
>>> linking/archiving
>>> libraries in DPDK.
>>>
>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>> removes the makefiles associated with building a combined library.
>>>
>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>> always generate a linker script that acts as a single combined library.
>>>
>>> Signed-off-by: Sergio Gonzalez Monroy 
>>> <sergio.gonzalez.monroy@intel.com>
>> No. We use combined library and it greatly simplfies the application
>> linking process.
>>
> After all the opposition this patch had in v2, I did explain the 
> current issues
> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this 
> was the agreed solution.
>
> As I mention in the cover letter (also see patch 2/5), building DPDK 
> (after applying this patch series) will always generate a very simple 
> linker script that behaves as a combined library.
> I encourage you to apply this patch series and try to build your app 
> (which links against combined lib).
> Your app should build without problem unless I messed up somewhere and 
> it needs fixing.

Is it possible to generate a pkgconfig file (dpdk.pc) that contains all 
of the setting needed to compile and link with dpdk?  That will greatly 
simplify usage.

A linker script is just too esoteric.

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09  9:06       ` Avi Kivity
@ 2015-04-09  9:42         ` Gonzalez Monroy, Sergio
  2015-04-09 11:19         ` Neil Horman
  1 sibling, 0 replies; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-09  9:42 UTC (permalink / raw)
  To: Avi Kivity; +Cc: dev

On 09/04/2015 10:06, Avi Kivity wrote:
>
>
> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>> On Wed,  8 Apr 2015 16:07:21 +0100
>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>
>>>> Currently, the target/rules to build combined libraries is different
>>>> than the one to build individual libraries.
>>>>
>>>> By removing the combined library option as a build configuration 
>>>> option
>>>> we simplify the build pocess by having a single point for 
>>>> linking/archiving
>>>> libraries in DPDK.
>>>>
>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option 
>>>> and
>>>> removes the makefiles associated with building a combined library.
>>>>
>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>> always generate a linker script that acts as a single combined 
>>>> library.
>>>>
>>>> Signed-off-by: Sergio Gonzalez Monroy 
>>>> <sergio.gonzalez.monroy@intel.com>
>>> No. We use combined library and it greatly simplfies the application
>>> linking process.
>>>
>> After all the opposition this patch had in v2, I did explain the 
>> current issues
>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and 
>> this was the agreed solution.
>>
>> As I mention in the cover letter (also see patch 2/5), building DPDK 
>> (after applying this patch series) will always generate a very simple 
>> linker script that behaves as a combined library.
>> I encourage you to apply this patch series and try to build your app 
>> (which links against combined lib).
>> Your app should build without problem unless I messed up somewhere 
>> and it needs fixing.
>
> Is it possible to generate a pkgconfig file (dpdk.pc) that contains 
> all of the setting needed to compile and link with dpdk? That will 
> greatly simplify usage.
>
> A linker script is just too esoteric.
>
>
That sounds very interesting.

I would be in favor of dropping the linker script for this solution if 
everybody is happy with it.

Sergio

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09  9:06       ` Avi Kivity
  2015-04-09  9:42         ` Gonzalez Monroy, Sergio
@ 2015-04-09 11:19         ` Neil Horman
  2015-04-09 13:33           ` Thomas Monjalon
  2015-04-09 17:00           ` Avi Kivity
  1 sibling, 2 replies; 18+ messages in thread
From: Neil Horman @ 2015-04-09 11:19 UTC (permalink / raw)
  To: Avi Kivity; +Cc: dev

On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> 
> 
> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> >On 08/04/2015 19:26, Stephen Hemminger wrote:
> >>On Wed,  8 Apr 2015 16:07:21 +0100
> >>Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> >>
> >>>Currently, the target/rules to build combined libraries is different
> >>>than the one to build individual libraries.
> >>>
> >>>By removing the combined library option as a build configuration option
> >>>we simplify the build pocess by having a single point for
> >>>linking/archiving
> >>>libraries in DPDK.
> >>>
> >>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> >>>removes the makefiles associated with building a combined library.
> >>>
> >>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> >>>always generate a linker script that acts as a single combined library.
> >>>
> >>>Signed-off-by: Sergio Gonzalez Monroy
> >>><sergio.gonzalez.monroy@intel.com>
> >>No. We use combined library and it greatly simplfies the application
> >>linking process.
> >>
> >After all the opposition this patch had in v2, I did explain the current
> >issues
> >(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> >the agreed solution.
> >
> >As I mention in the cover letter (also see patch 2/5), building DPDK
> >(after applying this patch series) will always generate a very simple
> >linker script that behaves as a combined library.
> >I encourage you to apply this patch series and try to build your app
> >(which links against combined lib).
> >Your app should build without problem unless I messed up somewhere and it
> >needs fixing.
> 
> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> the setting needed to compile and link with dpdk?  That will greatly
> simplify usage.
> 
> A linker script is just too esoteric.
> 
Why esoteric?  We're not talking about a linker script in the sense of a binary
layout file, we're talking about a prewritten/generated libdpdk_core.so that
contains linker directives to include the appropriate libraries.  You link it
just like you do any other library, but it lets you ignore how they are broken
up.

We could certainly do a pkg-config file, but I don't think thats any more
adventageous than this solution.

Neil

> 
> 

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09 11:19         ` Neil Horman
@ 2015-04-09 13:33           ` Thomas Monjalon
  2015-04-09 13:47             ` Gonzalez Monroy, Sergio
  2015-04-09 17:00           ` Avi Kivity
  1 sibling, 1 reply; 18+ messages in thread
From: Thomas Monjalon @ 2015-04-09 13:33 UTC (permalink / raw)
  To: Neil Horman, Avi Kivity; +Cc: dev

2015-04-09 07:19, Neil Horman:
> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> > On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> > >On 08/04/2015 19:26, Stephen Hemminger wrote:
> > >>On Wed,  8 Apr 2015 16:07:21 +0100
> > >>Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> > >>
> > >>>Currently, the target/rules to build combined libraries is different
> > >>>than the one to build individual libraries.
> > >>>
> > >>>By removing the combined library option as a build configuration option
> > >>>we simplify the build pocess by having a single point for
> > >>>linking/archiving
> > >>>libraries in DPDK.
> > >>>
> > >>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> > >>>removes the makefiles associated with building a combined library.
> > >>>
> > >>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> > >>>always generate a linker script that acts as a single combined library.
> > >>>
> > >>>Signed-off-by: Sergio Gonzalez Monroy
> > >>><sergio.gonzalez.monroy@intel.com>
> > >>No. We use combined library and it greatly simplfies the application
> > >>linking process.
> > >>
> > >After all the opposition this patch had in v2, I did explain the current
> > >issues
> > >(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> > >the agreed solution.
> > >
> > >As I mention in the cover letter (also see patch 2/5), building DPDK
> > >(after applying this patch series) will always generate a very simple
> > >linker script that behaves as a combined library.
> > >I encourage you to apply this patch series and try to build your app
> > >(which links against combined lib).
> > >Your app should build without problem unless I messed up somewhere and it
> > >needs fixing.
> > 
> > Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> > the setting needed to compile and link with dpdk?  That will greatly
> > simplify usage.
> > 
> > A linker script is just too esoteric.
> > 
> Why esoteric?  We're not talking about a linker script in the sense of a binary
> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> contains linker directives to include the appropriate libraries.  You link it
> just like you do any other library, but it lets you ignore how they are broken
> up.
> 
> We could certainly do a pkg-config file, but I don't think thats any more
> adventageous than this solution.

As already commented (http://dpdk.org/ml/archives/dev/2015-March/015367.html),
pkgconfig could be something useful in any case (single or multi-libraries).
Having a linker script to replace the single ("combined") library may be
convenient in some cases but do not replace pkgconfig.

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09 13:33           ` Thomas Monjalon
@ 2015-04-09 13:47             ` Gonzalez Monroy, Sergio
  0 siblings, 0 replies; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-09 13:47 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev

On 09/04/2015 14:33, Thomas Monjalon wrote:
> 2015-04-09 07:19, Neil Horman:
>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>>> On Wed,  8 Apr 2015 16:07:21 +0100
>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>>>
>>>>>> Currently, the target/rules to build combined libraries is different
>>>>>> than the one to build individual libraries.
>>>>>>
>>>>>> By removing the combined library option as a build configuration option
>>>>>> we simplify the build pocess by having a single point for
>>>>>> linking/archiving
>>>>>> libraries in DPDK.
>>>>>>
>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>>>>> removes the makefiles associated with building a combined library.
>>>>>>
>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>>>> always generate a linker script that acts as a single combined library.
>>>>>>
>>>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>>>> <sergio.gonzalez.monroy@intel.com>
>>>>> No. We use combined library and it greatly simplfies the application
>>>>> linking process.
>>>>>
>>>> After all the opposition this patch had in v2, I did explain the current
>>>> issues
>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
>>>> the agreed solution.
>>>>
>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
>>>> (after applying this patch series) will always generate a very simple
>>>> linker script that behaves as a combined library.
>>>> I encourage you to apply this patch series and try to build your app
>>>> (which links against combined lib).
>>>> Your app should build without problem unless I messed up somewhere and it
>>>> needs fixing.
>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
>>> the setting needed to compile and link with dpdk?  That will greatly
>>> simplify usage.
>>>
>>> A linker script is just too esoteric.
>>>
>> Why esoteric?  We're not talking about a linker script in the sense of a binary
>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
>> contains linker directives to include the appropriate libraries.  You link it
>> just like you do any other library, but it lets you ignore how they are broken
>> up.
>>
>> We could certainly do a pkg-config file, but I don't think thats any more
>> adventageous than this solution.
> As already commented (http://dpdk.org/ml/archives/dev/2015-March/015367.html),
I misunderstood the pkgconfig reference in your previous comment.
It seems even more trivial to generate the 'combined' linker script lib 
having a pkg-config file.
We could simplify much of the rte.app.mk by using a pkg-config file.

Sergio
> pkgconfig could be something useful in any case (single or multi-libraries).
> Having a linker script to replace the single ("combined") library may be
> convenient in some cases but do not replace pkgconfig.
>

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09 11:19         ` Neil Horman
  2015-04-09 13:33           ` Thomas Monjalon
@ 2015-04-09 17:00           ` Avi Kivity
  2015-04-09 20:34             ` Neil Horman
  1 sibling, 1 reply; 18+ messages in thread
From: Avi Kivity @ 2015-04-09 17:00 UTC (permalink / raw)
  To: Neil Horman; +Cc: dev

On 04/09/2015 02:19 PM, Neil Horman wrote:
> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>
>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>> On Wed,  8 Apr 2015 16:07:21 +0100
>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>>
>>>>> Currently, the target/rules to build combined libraries is different
>>>>> than the one to build individual libraries.
>>>>>
>>>>> By removing the combined library option as a build configuration option
>>>>> we simplify the build pocess by having a single point for
>>>>> linking/archiving
>>>>> libraries in DPDK.
>>>>>
>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>>>> removes the makefiles associated with building a combined library.
>>>>>
>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>>> always generate a linker script that acts as a single combined library.
>>>>>
>>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>>> <sergio.gonzalez.monroy@intel.com>
>>>> No. We use combined library and it greatly simplfies the application
>>>> linking process.
>>>>
>>> After all the opposition this patch had in v2, I did explain the current
>>> issues
>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
>>> the agreed solution.
>>>
>>> As I mention in the cover letter (also see patch 2/5), building DPDK
>>> (after applying this patch series) will always generate a very simple
>>> linker script that behaves as a combined library.
>>> I encourage you to apply this patch series and try to build your app
>>> (which links against combined lib).
>>> Your app should build without problem unless I messed up somewhere and it
>>> needs fixing.
>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
>> the setting needed to compile and link with dpdk?  That will greatly
>> simplify usage.
>>
>> A linker script is just too esoteric.
>>
> Why esoteric?  We're not talking about a linker script in the sense of a binary
> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> contains linker directives to include the appropriate libraries.  You link it
> just like you do any other library, but it lets you ignore how they are broken
> up.

You mean DT_NEEDED?  That's great, but it shouldn't be called a linker 
script.

> We could certainly do a pkg-config file, but I don't think thats any more
> adventageous than this solution.

It solves more problems -- cflags etc.  Of course having the right 
DT_NEEDED is a good thing regardless.

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09 17:00           ` Avi Kivity
@ 2015-04-09 20:34             ` Neil Horman
  2015-04-13  9:52               ` Gonzalez Monroy, Sergio
  0 siblings, 1 reply; 18+ messages in thread
From: Neil Horman @ 2015-04-09 20:34 UTC (permalink / raw)
  To: Avi Kivity; +Cc: dev

On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
> On 04/09/2015 02:19 PM, Neil Horman wrote:
> >On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> >>
> >>On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> >>>On 08/04/2015 19:26, Stephen Hemminger wrote:
> >>>>On Wed,  8 Apr 2015 16:07:21 +0100
> >>>>Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> >>>>
> >>>>>Currently, the target/rules to build combined libraries is different
> >>>>>than the one to build individual libraries.
> >>>>>
> >>>>>By removing the combined library option as a build configuration option
> >>>>>we simplify the build pocess by having a single point for
> >>>>>linking/archiving
> >>>>>libraries in DPDK.
> >>>>>
> >>>>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> >>>>>removes the makefiles associated with building a combined library.
> >>>>>
> >>>>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> >>>>>always generate a linker script that acts as a single combined library.
> >>>>>
> >>>>>Signed-off-by: Sergio Gonzalez Monroy
> >>>>><sergio.gonzalez.monroy@intel.com>
> >>>>No. We use combined library and it greatly simplfies the application
> >>>>linking process.
> >>>>
> >>>After all the opposition this patch had in v2, I did explain the current
> >>>issues
> >>>(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> >>>the agreed solution.
> >>>
> >>>As I mention in the cover letter (also see patch 2/5), building DPDK
> >>>(after applying this patch series) will always generate a very simple
> >>>linker script that behaves as a combined library.
> >>>I encourage you to apply this patch series and try to build your app
> >>>(which links against combined lib).
> >>>Your app should build without problem unless I messed up somewhere and it
> >>>needs fixing.
> >>Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> >>the setting needed to compile and link with dpdk?  That will greatly
> >>simplify usage.
> >>
> >>A linker script is just too esoteric.
> >>
> >Why esoteric?  We're not talking about a linker script in the sense of a binary
> >layout file, we're talking about a prewritten/generated libdpdk_core.so that
> >contains linker directives to include the appropriate libraries.  You link it
> >just like you do any other library, but it lets you ignore how they are broken
> >up.
> 
> You mean DT_NEEDED?  That's great, but it shouldn't be called a linker
> script.
> 
no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
sergio wrote is.

> >We could certainly do a pkg-config file, but I don't think thats any more
> >adventageous than this solution.
> 
> It solves more problems -- cflags etc.  Of course having the right DT_NEEDED
> is a good thing regardless.
> 
Thats a good point, pkgconfig doesn't provide that additionally.  Perhaps having
both is the best solution.  As for the DT_NEEDED issues, the earlier threads
ennumerated all the problems that were being found with the way the libraries
were organized (circular dependencies).

Neil

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-09 20:34             ` Neil Horman
@ 2015-04-13  9:52               ` Gonzalez Monroy, Sergio
  2015-04-13 11:04                 ` Thomas Monjalon
  0 siblings, 1 reply; 18+ messages in thread
From: Gonzalez Monroy, Sergio @ 2015-04-13  9:52 UTC (permalink / raw)
  To: Neil Horman; +Cc: dev

On 09/04/2015 21:34, Neil Horman wrote:
> On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
>> On 04/09/2015 02:19 PM, Neil Horman wrote:
>>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>>>> On Wed,  8 Apr 2015 16:07:21 +0100
>>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
>>>>>>
>>>>>>> Currently, the target/rules to build combined libraries is different
>>>>>>> than the one to build individual libraries.
>>>>>>>
>>>>>>> By removing the combined library option as a build configuration option
>>>>>>> we simplify the build pocess by having a single point for
>>>>>>> linking/archiving
>>>>>>> libraries in DPDK.
>>>>>>>
>>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
>>>>>>> removes the makefiles associated with building a combined library.
>>>>>>>
>>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
>>>>>>> always generate a linker script that acts as a single combined library.
>>>>>>>
>>>>>>> Signed-off-by: Sergio Gonzalez Monroy
>>>>>>> <sergio.gonzalez.monroy@intel.com>
>>>>>> No. We use combined library and it greatly simplfies the application
>>>>>> linking process.
>>>>>>
>>>>> After all the opposition this patch had in v2, I did explain the current
>>>>> issues
>>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
>>>>> the agreed solution.
>>>>>
>>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
>>>>> (after applying this patch series) will always generate a very simple
>>>>> linker script that behaves as a combined library.
>>>>> I encourage you to apply this patch series and try to build your app
>>>>> (which links against combined lib).
>>>>> Your app should build without problem unless I messed up somewhere and it
>>>>> needs fixing.
>>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
>>>> the setting needed to compile and link with dpdk?  That will greatly
>>>> simplify usage.
>>>>
>>>> A linker script is just too esoteric.
>>>>
>>> Why esoteric?  We're not talking about a linker script in the sense of a binary
>>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
>>> contains linker directives to include the appropriate libraries.  You link it
>>> just like you do any other library, but it lets you ignore how they are broken
>>> up.
>> You mean DT_NEEDED?  That's great, but it shouldn't be called a linker
>> script.
>>
> no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
> sergio wrote is.
>
>>> We could certainly do a pkg-config file, but I don't think thats any more
>>> adventageous than this solution.
>> It solves more problems -- cflags etc.  Of course having the right DT_NEEDED
>> is a good thing regardless.
>>
> Thats a good point, pkgconfig doesn't provide that additionally.  Perhaps having
> both is the best solution.  As for the DT_NEEDED issues, the earlier threads
> ennumerated all the problems that were being found with the way the libraries
> were organized (circular dependencies).
>
> Neil
I am not entirely sure of the conclusion of this thread.

Are we happy with the current linker script solution as a replacement of 
the combined lib?
Do we want to provide pkg-config file in addition or instead of linker 
script?

I think I will split the series as there seems to be no objections to 
the patches related to DT_NEEDED entries.
I'll post a series for DT_NEEDED entries and another series for dealing 
with the combined lib (once we get to an agreement).

Does it sound reasonable?

Sergio

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-13  9:52               ` Gonzalez Monroy, Sergio
@ 2015-04-13 11:04                 ` Thomas Monjalon
  2015-04-13 11:23                   ` Neil Horman
  0 siblings, 1 reply; 18+ messages in thread
From: Thomas Monjalon @ 2015-04-13 11:04 UTC (permalink / raw)
  To: Gonzalez Monroy, Sergio; +Cc: dev

2015-04-13 10:52, Gonzalez Monroy, Sergio:
> On 09/04/2015 21:34, Neil Horman wrote:
> > On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
> >> On 04/09/2015 02:19 PM, Neil Horman wrote:
> >>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> >>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> >>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
> >>>>>> On Wed,  8 Apr 2015 16:07:21 +0100
> >>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> >>>>>>
> >>>>>>> Currently, the target/rules to build combined libraries is different
> >>>>>>> than the one to build individual libraries.
> >>>>>>>
> >>>>>>> By removing the combined library option as a build configuration option
> >>>>>>> we simplify the build pocess by having a single point for
> >>>>>>> linking/archiving
> >>>>>>> libraries in DPDK.
> >>>>>>>
> >>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> >>>>>>> removes the makefiles associated with building a combined library.
> >>>>>>>
> >>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> >>>>>>> always generate a linker script that acts as a single combined library.
> >>>>>>>
> >>>>>>> Signed-off-by: Sergio Gonzalez Monroy
> >>>>>>> <sergio.gonzalez.monroy@intel.com>
> >>>>>> No. We use combined library and it greatly simplfies the application
> >>>>>> linking process.
> >>>>>>
> >>>>> After all the opposition this patch had in v2, I did explain the current
> >>>>> issues
> >>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> >>>>> the agreed solution.
> >>>>>
> >>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
> >>>>> (after applying this patch series) will always generate a very simple
> >>>>> linker script that behaves as a combined library.
> >>>>> I encourage you to apply this patch series and try to build your app
> >>>>> (which links against combined lib).
> >>>>> Your app should build without problem unless I messed up somewhere and it
> >>>>> needs fixing.
> >>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> >>>> the setting needed to compile and link with dpdk?  That will greatly
> >>>> simplify usage.
> >>>>
> >>>> A linker script is just too esoteric.
> >>>>
> >>> Why esoteric?  We're not talking about a linker script in the sense of a binary
> >>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> >>> contains linker directives to include the appropriate libraries.  You link it
> >>> just like you do any other library, but it lets you ignore how they are broken
> >>> up.
> >> You mean DT_NEEDED?  That's great, but it shouldn't be called a linker
> >> script.
> >>
> > no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
> > sergio wrote is.
> >
> >>> We could certainly do a pkg-config file, but I don't think thats any more
> >>> adventageous than this solution.
> >> It solves more problems -- cflags etc.  Of course having the right DT_NEEDED
> >> is a good thing regardless.
> >>
> > Thats a good point, pkgconfig doesn't provide that additionally.  Perhaps having
> > both is the best solution.  As for the DT_NEEDED issues, the earlier threads
> > ennumerated all the problems that were being found with the way the libraries
> > were organized (circular dependencies).
> >
> > Neil
> I am not entirely sure of the conclusion of this thread.
> 
> Are we happy with the current linker script solution as a replacement of 
> the combined lib?
> Do we want to provide pkg-config file in addition or instead of linker 
> script?

Yes pkg-config should be an addition on top of shared/static split/combined
libraries (or linker script). It should be an alternative to mk/rte.app.mk.

> I think I will split the series as there seems to be no objections to 
> the patches related to DT_NEEDED entries.
> I'll post a series for DT_NEEDED entries and another series for dealing 
> with the combined lib (once we get to an agreement).
> 
> Does it sound reasonable?

Yes good idea, thanks.

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

* Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options
  2015-04-13 11:04                 ` Thomas Monjalon
@ 2015-04-13 11:23                   ` Neil Horman
  0 siblings, 0 replies; 18+ messages in thread
From: Neil Horman @ 2015-04-13 11:23 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev

On Mon, Apr 13, 2015 at 01:04:52PM +0200, Thomas Monjalon wrote:
> 2015-04-13 10:52, Gonzalez Monroy, Sergio:
> > On 09/04/2015 21:34, Neil Horman wrote:
> > > On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote:
> > >> On 04/09/2015 02:19 PM, Neil Horman wrote:
> > >>> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
> > >>>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> > >>>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
> > >>>>>> On Wed,  8 Apr 2015 16:07:21 +0100
> > >>>>>> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> > >>>>>>
> > >>>>>>> Currently, the target/rules to build combined libraries is different
> > >>>>>>> than the one to build individual libraries.
> > >>>>>>>
> > >>>>>>> By removing the combined library option as a build configuration option
> > >>>>>>> we simplify the build pocess by having a single point for
> > >>>>>>> linking/archiving
> > >>>>>>> libraries in DPDK.
> > >>>>>>>
> > >>>>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and
> > >>>>>>> removes the makefiles associated with building a combined library.
> > >>>>>>>
> > >>>>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to
> > >>>>>>> always generate a linker script that acts as a single combined library.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Sergio Gonzalez Monroy
> > >>>>>>> <sergio.gonzalez.monroy@intel.com>
> > >>>>>> No. We use combined library and it greatly simplfies the application
> > >>>>>> linking process.
> > >>>>>>
> > >>>>> After all the opposition this patch had in v2, I did explain the current
> > >>>>> issues
> > >>>>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was
> > >>>>> the agreed solution.
> > >>>>>
> > >>>>> As I mention in the cover letter (also see patch 2/5), building DPDK
> > >>>>> (after applying this patch series) will always generate a very simple
> > >>>>> linker script that behaves as a combined library.
> > >>>>> I encourage you to apply this patch series and try to build your app
> > >>>>> (which links against combined lib).
> > >>>>> Your app should build without problem unless I messed up somewhere and it
> > >>>>> needs fixing.
> > >>>> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of
> > >>>> the setting needed to compile and link with dpdk?  That will greatly
> > >>>> simplify usage.
> > >>>>
> > >>>> A linker script is just too esoteric.
> > >>>>
> > >>> Why esoteric?  We're not talking about a linker script in the sense of a binary
> > >>> layout file, we're talking about a prewritten/generated libdpdk_core.so that
> > >>> contains linker directives to include the appropriate libraries.  You link it
> > >>> just like you do any other library, but it lets you ignore how they are broken
> > >>> up.
> > >> You mean DT_NEEDED?  That's great, but it shouldn't be called a linker
> > >> script.
> > >>
> > > no, I don't mean DT_NEEDED, I mean a linker script, because thats what what
> > > sergio wrote is.
> > >
> > >>> We could certainly do a pkg-config file, but I don't think thats any more
> > >>> adventageous than this solution.
> > >> It solves more problems -- cflags etc.  Of course having the right DT_NEEDED
> > >> is a good thing regardless.
> > >>
> > > Thats a good point, pkgconfig doesn't provide that additionally.  Perhaps having
> > > both is the best solution.  As for the DT_NEEDED issues, the earlier threads
> > > ennumerated all the problems that were being found with the way the libraries
> > > were organized (circular dependencies).
> > >
> > > Neil
> > I am not entirely sure of the conclusion of this thread.
> > 
> > Are we happy with the current linker script solution as a replacement of 
> > the combined lib?
> > Do we want to provide pkg-config file in addition or instead of linker 
> > script?
> 
> Yes pkg-config should be an addition on top of shared/static split/combined
> libraries (or linker script). It should be an alternative to mk/rte.app.mk.
> 

Adding a pkg-config file I think makes lots of sense.

> > I think I will split the series as there seems to be no objections to 
> > the patches related to DT_NEEDED entries.
> > I'll post a series for DT_NEEDED entries and another series for dealing 
> > with the combined lib (once we get to an agreement).
> > 
> > Does it sound reasonable?
> 
yup
> 

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

end of thread, other threads:[~2015-04-13 11:23 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-08 15:07 [dpdk-dev] [PATCH v3 0/5] Enhance build process Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options Sergio Gonzalez Monroy
2015-04-08 18:26   ` Stephen Hemminger
2015-04-09  8:33     ` Gonzalez Monroy, Sergio
2015-04-09  9:06       ` Avi Kivity
2015-04-09  9:42         ` Gonzalez Monroy, Sergio
2015-04-09 11:19         ` Neil Horman
2015-04-09 13:33           ` Thomas Monjalon
2015-04-09 13:47             ` Gonzalez Monroy, Sergio
2015-04-09 17:00           ` Avi Kivity
2015-04-09 20:34             ` Neil Horman
2015-04-13  9:52               ` Gonzalez Monroy, Sergio
2015-04-13 11:04                 ` Thomas Monjalon
2015-04-13 11:23                   ` Neil Horman
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 2/5] mk: always generate combined lib linker script Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 3/5] lib: set LDLIBS for each library Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 4/5] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-04-08 15:07 ` [dpdk-dev] [PATCH v3 5/5] mk: update LDLIBS for app building Sergio Gonzalez Monroy

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