From: Neil Horman <nhorman@tuxdriver.com>
To: Stefan Puiu <stefan.puiu@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options
Date: Wed, 18 Mar 2015 12:48:04 -0400 [thread overview]
Message-ID: <20150318164804.GB362@hmsreliant.think-freely.org> (raw)
In-Reply-To: <CACKs7VBNmmdPoBcv-vPpn-HVQr2Nd2Gr_2shTuqdh2L1MsfY_Q@mail.gmail.com>
On Wed, Mar 18, 2015 at 05:30:12PM +0200, Stefan Puiu wrote:
> Hi,
>
> On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > Hi Sergio,
> >
> > Thank you for explaining the situation.
> >
> > 2015-03-18 12:11, Gonzalez Monroy, Sergio:
> >> Given that the patch to remove combined libraries is not welcome, I'll
> >> try to explain the current situation so we can agree on the way forward.
> >>
> >> Currently we have build config option for shared libraries and combined
> >> libraries. Thus, this results in four possible combinations when
> >> building dpdk:
> >> - not combined static
> >> - not combined shared
> >> - combined static
> >> - combined shared
> >>
> >> The makefile rules/targets for combined are different than for not
> >> combined. Thus, we currently have two different files for
> >> archive/linking (rte.lib.mk and rte.sharelib.mk).
> >>
> >> Since having versioning, combined shared libraries build will be broken
> >> the moment we add a versioned API, as we do not have a global version
> >> map that we use when linking such library.
> >> Also in my opinion, we would want to prevent users linking against a
> >> combined libdpdk.so that may have different features built-in, with the
> >> corresponding debugging difficulties when users
> >> report different problems/errors. I think this would defeat many of the
> >> advantages of using shared libraries.
> >>
> >> By removing the combined library build option, we would simplify the
> >> build system with only two possible choices:
> >> - static
> >> - shared
> >
> > +1
> > I believe that simplification is the way go.
> >
> >> This would allow us to remove one file (rte.sharelib.mk) and have a
> >> single file with archive/linking rules.
> >>
> >> For the convenience of linking against a single library instead of the
> >> multiple dpdk libraries, there are a few ways to go around it:
> >> - for combined static lib, we can either have a script to re-archive
> >> all libraries into a single/combined library (ie. extract all archives
> >> into one directory, the re-archive all objects into a combined library),
> >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ).
>
> Would the linker script be provided in the repository or would it be
> the responsibility of people building against the DPDK? If I'd need to
> make a linker script with the list of libraries to link against, might
> as well put that list in my SConstruct / Makefile and be done with it.
> So the "write your own linker script" and "just deal with separate
> libraries" options don't seem that different to me.
>
just to level set, I think you're thinking of a linker script in too grand a
scale. Technically what we're proposing is a linker script, but its literally a
single line. If you want an example take a look at /usr/lib64/libc.so.
that said, I think it makes more sense for the linker script in question to be
part of the dpdk distribution so that the combined library name picks up new
libraries as they are created.
> Let me ask you something - I understand your concerns about
> simplifying Makefiles and the concerns about versioning. How
> significant is the "separate libs" use case? And especially the
> "separate libs" in the current division of the code / libraries? I
> counted about ~30 libs in 1.8.0 under build/lib. Are there people
> using librte_eal without rte_malloc? Or rte_malloc without
> rte_mempool?
>
Highly doubtful/impossible since they are explicitly dependent on one another.
> I noticed that some examples I built ended up using --whole-archive
> -lrte_eal -lrte_etc.... To me, --whole-archive is one way of saying
> "we have lots of libraries with obscure dependencies", maybe reducing
> the number of libs might also be a way to make the combined lib
> unnecessary? I wouldn't bother with the combined lib if I had 3-4 libs
> to link against instead of the number of libs needed now.
>
This isn't a bad suggestion. combining the low level malloc/mempool/eal
libraries into a libdpdk_core probably makes sense. Not sure if doing it right
now makes sense (this close to the release). But as a next release goal that
seems reasonable.
Neil
next prev parent reply other threads:[~2015-03-18 16:48 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 [this message]
2015-03-26 8:52 ` Gonzalez Monroy, Sergio
2015-03-26 10:30 ` Neil Horman
2015-03-18 16:41 ` Neil Horman
2015-03-12 16:27 ` [dpdk-dev] [PATCH v2 2/4] lib: Set LDLIBS for each library Sergio Gonzalez Monroy
2015-03-12 16:28 ` [dpdk-dev] [PATCH v2 3/4] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-03-12 16:28 ` [dpdk-dev] [PATCH v2 4/4] mk: update LDLIBS for app building Sergio Gonzalez Monroy
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=20150318164804.GB362@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=stefan.puiu@gmail.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).