From: Neil Horman <nhorman@tuxdriver.com>
To: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
Date: Thu, 26 Mar 2015 06:30:19 -0400 [thread overview]
Message-ID: <20150326103019.GA32299@hmsreliant.think-freely.org> (raw)
In-Reply-To: <5513C8CD.80408@intel.com>
On Thu, Mar 26, 2015 at 08:52:29AM +0000, Gonzalez Monroy, Sergio wrote:
> On 18/03/2015 12:59, Thomas Monjalon wrote:
> >Hi Sergio,
> >
> >Thank you for explaining the situation.
> >
> >2015-03-18 12:11, Gonzalez Monroy, Sergio:
> >>Given that the patch to remove combined libraries is not welcome, I'll
> >>try to explain the current situation so we can agree on the way forward.
> >>
> >>Currently we have build config option for shared libraries and combined
> >>libraries. Thus, this results in four possible combinations when
> >>building dpdk:
> >>- not combined static
> >>- not combined shared
> >>- combined static
> >>- combined shared
> >>
> >>The makefile rules/targets for combined are different than for not
> >>combined. Thus, we currently have two different files for
> >>archive/linking (rte.lib.mk and rte.sharelib.mk).
> >>
> >>Since having versioning, combined shared libraries build will be broken
> >>the moment we add a versioned API, as we do not have a global version
> >>map that we use when linking such library.
> >>Also in my opinion, we would want to prevent users linking against a
> >>combined libdpdk.so that may have different features built-in, with the
> >>corresponding debugging difficulties when users
> >>report different problems/errors. I think this would defeat many of the
> >>advantages of using shared libraries.
> >>
> >>By removing the combined library build option, we would simplify the
> >>build system with only two possible choices:
> >>- static
> >>- shared
> >+1
> >I believe that simplification is the way go.
> >
> >>This would allow us to remove one file (rte.sharelib.mk) and have a
> >>single file with archive/linking rules.
> >>
> >>For the convenience of linking against a single library instead of the
> >>multiple dpdk libraries, there are a few ways to go around it:
> >> - for combined static lib, we can either have a script to re-archive
> >>all libraries into a single/combined library (ie. extract all archives
> >>into one directory, the re-archive all objects into a combined library),
> >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ).
> >>- for combined shared lib, we can use a linker script (ie. INPUT (
> >>-lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a
> >>global version map (either somehow merging all independent version maps
> >>or maintaining a global version map).
> >>
> >>My preference would be to remove the combined libs as a build config
> >>option, then either add scripts to create those linker scripts or
> >>document it so users know how to create their own linker scripts.
> >>This would simplify the build process and still be able to provide the
> >>convenience of the combined library by using a linker script.
> >>
> >>Comments?
> >You're right about the word convenience.
> >There are many ways to provide such convenience.
> >The first one is to simply use the DPDK makefiles which abstract linking problems.
> >If using DPDK framework is not an option, we can add new conveniences like
> >scripts or pkgconfig support.
> >
> So for v3, do we provide such script/pkgconfig or just documentation on how
> to create it?
>
> Sergio
>
I think the former makes the most sense, personally. Provide a script or
automatically build the combined lib script during the build.
Neil
next prev parent reply other threads:[~2015-03-26 10:30 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-29 15:20 [dpdk-dev] [PATCH 0/8] Improve build process Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 1/8] mk: remove combined library and related options Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 2/8] core: create new librte_core Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 3/8] mk: new corelib makefile Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 4/8] lib: update DEPDIRS variable Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 5/8] lib: set LDLIBS for each library Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 6/8] mk: use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 7/8] mk: update LDLIBS for app building Sergio Gonzalez Monroy
2015-01-29 15:20 ` [dpdk-dev] [PATCH 8/8] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy
2015-01-29 16:38 ` [dpdk-dev] [PATCH 0/8] Improve build process Neil Horman
2015-01-29 17:02 ` Thomas Monjalon
2015-01-29 17:04 ` Gonzalez Monroy, Sergio
2015-01-29 19:45 ` Neil Horman
2015-01-30 13:39 ` Gonzalez Monroy, Sergio
2015-01-30 14:05 ` Neil Horman
2015-01-30 17:38 ` Gonzalez Monroy, Sergio
2015-01-30 18:12 ` Neil Horman
2015-02-11 11:11 ` Gonzalez Monroy, Sergio
2015-02-12 5:41 ` Neil Horman
2015-02-12 9:17 ` Gonzalez Monroy, Sergio
2015-02-12 12:16 ` Neil Horman
2015-02-12 9:22 ` Panu Matilainen
2015-02-12 10:03 ` Gonzalez Monroy, Sergio
2015-02-12 12:23 ` Neil Horman
2015-02-12 14:07 ` Panu Matilainen
2015-02-12 15:52 ` Neil Horman
2015-02-13 10:14 ` Panu Matilainen
2015-02-13 11:08 ` Gonzalez Monroy, Sergio
2015-02-13 12:51 ` Neil Horman
2015-02-20 14:31 ` Gonzalez Monroy, Sergio
2015-02-22 23:37 ` Neil Horman
2015-02-23 10:25 ` Gonzalez Monroy, Sergio
2015-02-23 13:52 ` Neil Horman
2015-02-23 14:58 ` Gonzalez Monroy, Sergio
2015-02-23 18:23 ` Neil Horman
2015-02-24 13:24 ` Gonzalez Monroy, Sergio
2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 0/4] " Sergio Gonzalez Monroy
2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options Sergio Gonzalez Monroy
2015-03-13 10:49 ` Kavanagh, Mark B
2015-03-13 11:19 ` Gonzalez Monroy, Sergio
2015-03-13 11:34 ` Kavanagh, Mark B
2015-03-13 11:48 ` Gonzalez Monroy, Sergio
2015-03-13 13:16 ` Kavanagh, Mark B
2015-03-13 14:11 ` Gonzalez Monroy, Sergio
2015-03-13 13:17 ` Neil Horman
2015-03-13 14:12 ` Stefan Puiu
2015-03-13 15:18 ` Neil Horman
2015-03-13 15:28 ` Gonzalez Monroy, Sergio
2015-03-13 16:16 ` Neil Horman
2015-03-13 16:07 ` Stephen Hemminger
2015-03-13 16:32 ` Neil Horman
2015-03-13 16:38 ` Gonzalez Monroy, Sergio
2015-03-18 12:11 ` Gonzalez Monroy, Sergio
2015-03-18 12:59 ` Thomas Monjalon
2015-03-18 15:30 ` Stefan Puiu
2015-03-18 15:52 ` Gonzalez Monroy, Sergio
2015-03-18 16:48 ` Neil Horman
2015-03-26 8:52 ` Gonzalez Monroy, Sergio
2015-03-26 10:30 ` Neil Horman [this message]
2015-03-18 16:41 ` Neil Horman
2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy
2015-03-12 16:28 ` [dpdk-dev] [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-03-12 16:28 ` [dpdk-dev] [PATCH v2 4/4] mk: update LDLIBS for app building Sergio Gonzalez Monroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150326103019.GA32299@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=sergio.gonzalez.monroy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).