Hi, Apologies for the previous email format, I seems like I misconfigured something on my email-client. In case people find it annoying to read with extra line spaces, here is the RFC with fixed formatting:
I would like to propose an update on the way the libraries are being built on DPDK. Motivation/Issues: - No agreement on libraries to build (separated, combined, different grouping). - People having issues building their applications cannot rely on the information given by ldd when using shared libraries because currently we are not building against dependent libraries. - External library dependencies are introduce in multiple places (ie. when building librte_vhost, -lfuse is added into the lib CFLAGS, LDFLAGS and also need to update rte.app.mk). - Do we want to keep support for building shared libraries using LD? Currently unused as both Linux and BSD enable linking using CC. Proposal: - Define external lib dependencies per module/lib/dir. ie. EXT_DEP_LIBS = -lfuse -lm - Define internal lib dependencies per module/lib/dir. ie. DPDK_DEP_LIBS = -lrte_eal - Remove compile config option CONFIG_RTE_BUILD_COMBINE_LIBS and always build all wanted libraries (see below about different libraries to build). - Shared linking: we want to link apps and libs against dependant libraries. Basically add EXT_DEP_LIBS and DPDK_DEP_LIBS when linking libs and apps. - Static linking: we want to link apps against dependant libraries. >From my point of view, we can classify DPDK libraries into three categories >(note that not all libraries are included and the following is just for >illustration purposes): CORE_LIBS: librte_kvargs, librte_mbuf, librte_malloc, librte_mempool, librte_ring, librte_eal, libethdev? NON_CORE_LIBS: librte_vhost, librte_cfgfile, librte_cmdline, librte_sched, librte_lpm, librte_acl, ... PMD_LIBS: librte_pmd_i40e, librte_pmd_e1000, librte_ixgbe, ... IMHO CORE_LIBS are a set of libraries that have inter-dependencies and are always required to build an application. Such set of core libraries should be provided as a single library. I can think of a few different ways to go about this: A) Build just one combined library for static or shared libraries. Pros: it would reduce and simplify makefile rules, as well as make it easier for users to build their own apps against DPDK. Cons: limited flexibility when building custom apps with selected libraries. Link apps with something like: --whole-archive -ldpdk --no-whole-archive --as-needed $(EXT_DEP_LIBS) --no-as-needed B) Build CORE_LIBS (as a single lib, librte_core), NON_CORE_LIBS and PMD_LIBS: Pros: flexibility. Cons: more complex build process, as we would add dependencies for each NON_CORE_LIB and PMD_LIB. Link apps with something like: --whole-archive $(PMD_LIBS) --no-whole-archive $(NON_CORE_LIBS) -lrte_core --as-needed $(EXT_DEP_LIBS) --no-as-needed C) Similar to B but building a single library containing both CORE_LIBS and NON_CORE_LIBS. Link apps with something like: --whole-archive $(PMD_LIBS) --no-whole-archive -lrte_xxxx --as-needed $(EXT_DEP_LIBS) --no-as-needed D) Build all libs in both A) and B) but linking DPDK provided apps only against combined lib for slightly simpler makefile rules. I would say that D) is a good balance, although not being the simplest. Thoughts? Thanks, Sergio