DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH RFC] Update/Improve build system
@ 2014-10-30  9:18 Gonzalez Monroy, Sergio
  2014-10-30 11:53 ` Gonzalez Monroy, Sergio
  2014-10-30 20:50 ` Matthew Hall
  0 siblings, 2 replies; 6+ messages in thread
From: Gonzalez Monroy, Sergio @ 2014-10-30  9:18 UTC (permalink / raw)
  To: dev


I would like to propose an update on the way the libraries are being built on DPDK.


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


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




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

end of thread, other threads:[~2014-11-01 12:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-30  9:18 [dpdk-dev] [PATCH RFC] Update/Improve build system Gonzalez Monroy, Sergio
2014-10-30 11:53 ` Gonzalez Monroy, Sergio
2014-10-30 20:50 ` Matthew Hall
2014-10-31 10:45   ` Gonzalez Monroy, Sergio
2014-10-31 22:33     ` Matthew Hall
2014-11-01 12:53     ` Neil Horman

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git