From: Jan Blunck <jblunck@infradead.org>
To: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Cc: dev <dev@dpdk.org>,
"cjcollier @ linuxfoundation . org"
<cjcollier@linuxfoundation.org>,
ricardo.salveti@linaro.org,
Luca Boccassi <luca.boccassi@gmail.com>
Subject: Re: [dpdk-dev] [PATCH v2] mk: Provide option to set Major ABI version
Date: Wed, 1 Mar 2017 15:35:52 +0100 [thread overview]
Message-ID: <CALe+Z03-PzvnO_TeYQDMeT6MQw4eExYKkcwLxHP0kMS14cL9jg@mail.gmail.com> (raw)
In-Reply-To: <1488360852-14458-1-git-send-email-christian.ehrhardt@canonical.com>
On Wed, Mar 1, 2017 at 10:34 AM, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> Downstreams might want to provide different DPDK releases at the same
> time to support multiple consumers of DPDK linked against older and newer
> sonames.
>
> Also due to the interdependencies that DPDK libraries can have applications
> might end up with an executable space in which multiple versions of a
> library are mapped by ld.so.
>
> Think of LibA that got an ABI bump and LibB that did not get an ABI bump
> but is depending on LibA.
>
> Application
> \-> LibA.old
> \-> LibB.new -> LibA.new
>
> That is a conflict which can be avoided by setting CONFIG_RTE_MAJOR_ABI.
> If set CONFIG_RTE_MAJOR_ABI overwrites any LIBABIVER value.
> An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all
> libraries librte<?>.so.16.11 instead of librte<?>.so.<LIBABIVER>.
>
> We need to cut arbitrary long stings after the .so now and this would work
> for any ABI version in LIBABIVER:
> $(Q)ln -s -f $< $(patsubst %.$(LIBABIVER),%,$@)
> But using the following instead additionally allows to simplify the Make
> File for the CONFIG_RTE_NEXT_ABI case.
> $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
>
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
> config/common_base | 5 +++++
> doc/guides/contributing/versioning.rst | 25 +++++++++++++++++++++++++
> mk/rte.lib.mk | 14 +++++++++-----
> 3 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/config/common_base b/config/common_base
> index aeee13e..37aa1e1 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -75,6 +75,11 @@ CONFIG_RTE_BUILD_SHARED_LIB=n
> CONFIG_RTE_NEXT_ABI=y
>
> #
> +# Major ABI to overwrite library specific LIBABIVER
> +#
> +CONFIG_RTE_MAJOR_ABI=
> +
> +#
> # Machine's cache line size
> #
> CONFIG_RTE_CACHE_LINE_SIZE=64
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index fbc44a7..8aaf370 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -133,6 +133,31 @@ The macros exported are:
> fully qualified function ``p``, so that if a symbol becomes versioned, it
> can still be mapped back to the public symbol name.
>
> +Setting a Major ABI version
> +---------------------------
> +
> +Downstreams might want to provide different DPDK releases at the same time to
> +support multiple consumers of DPDK linked against older and newer sonames.
> +
> +Also due to the interdependencies that DPDK libraries can have applications
> +might end up with an executable space in which multiple versions of a library
> +are mapped by ld.so.
> +
> +Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
> +depending on LibA.
> +
> +.. note::
> +
> + Application
> + \-> LibA.old
> + \-> LibB.new -> LibA.new
> +
> +That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
> +If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
> +library - versions defined in the libraries ``LIBABIVER``.
> +An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
> +``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
> +
> Examples of ABI Macro use
> -------------------------
>
> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
> index 33a5f5a..1ffbf42 100644
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -40,12 +40,20 @@ EXTLIB_BUILD ?= n
> # VPATH contains at least SRCDIR
> VPATH += $(SRCDIR)
>
> +ifneq ($(CONFIG_RTE_MAJOR_ABI),)
> +ifneq ($(LIBABIVER),)
> +LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
> +endif
> +endif
> +
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
> ifeq ($(EXTLIB_BUILD),n)
> +ifeq ($(CONFIG_RTE_MAJOR_ABI),)
> ifeq ($(CONFIG_RTE_NEXT_ABI),y)
> LIB := $(LIB).1
> endif
> +endif
> CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
> endif
> endif
> @@ -156,11 +164,7 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
> @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
> $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> -ifeq ($(CONFIG_RTE_NEXT_ABI)$(EXTLIB_BUILD),yn)
> - $(Q)ln -s -f $< $(basename $(basename $@))
> -else
> - $(Q)ln -s -f $< $(basename $@)
> -endif
> + $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
> endif
>
> #
> --
> 2.7.4
>
Reviewed-by: Jan Blunck <jblunck@infradead.org>
Tested-by: Jan Blunck <jblunck@infradead.org>
next prev parent reply other threads:[~2017-03-01 14:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 10:52 [dpdk-dev] Further fun with ABI tracking Christian Ehrhardt
2017-02-14 16:19 ` Bruce Richardson
2017-02-14 20:31 ` Jan Blunck
2017-02-22 13:12 ` Christian Ehrhardt
2017-02-22 13:24 ` [dpdk-dev] [PATCH] mk: Provide option to set Major ABI version Christian Ehrhardt
2017-02-28 8:34 ` Jan Blunck
2017-03-01 9:31 ` Christian Ehrhardt
2017-03-01 9:34 ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
2017-03-01 14:35 ` Jan Blunck [this message]
2017-03-16 17:19 ` Thomas Monjalon
2017-03-17 8:27 ` Christian Ehrhardt
2017-03-17 9:16 ` Jan Blunck
2017-02-23 18:48 ` [dpdk-dev] Further fun with ABI tracking Ferruh Yigit
2017-02-24 7:32 ` Christian Ehrhardt
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=CALe+Z03-PzvnO_TeYQDMeT6MQw4eExYKkcwLxHP0kMS14cL9jg@mail.gmail.com \
--to=jblunck@infradead.org \
--cc=christian.ehrhardt@canonical.com \
--cc=cjcollier@linuxfoundation.org \
--cc=dev@dpdk.org \
--cc=luca.boccassi@gmail.com \
--cc=ricardo.salveti@linaro.org \
/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).