ABI version of experimental libraries
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39
Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine.
When we'll switch to the new major ABI and use a normal numbering:
In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
PATCH 1/1 build: fix soname for experimental libraries
Because of an original mistake in ABI numbering, and a temporary workaround for ABI 20,
for experimental libs, numbering would lead to consider
ABI 20.1 > ABI 21.0
Before this patch:
DPDK 19.11: ABI version 0.200 and soname 0.20 DPDK 20.02: ABI version 0.2001 and soname 0.201 Numbers are increasing, that's fine.
For the next major ABI, back to normal numbering:
DPDK 20.11: ABI version 0.210 and soname 0.21 Numbers are decreasing!
After this patch:
DPDK 19.11: ABI version 0.200 and soname 0.20 DPDK 20.02: ABI version 0.201 and soname 0.20 DPDK 20.11: ABI version 0.210 and soname 0.21
--- config/meson.build | 8 ++++---- mk/rte.lib.mk | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)
config/meson.build +4 -4
@@ -27,12 +27,12 @@ abi_version = run_command(find_program('cat', 'more'), # and the filename suffix as 0.majorminor versions, # e.g. v20.1 => librte_stable.so.20.1, librte_experimental.so.0.201 # sonames => librte_stable.so.20, librte_experimental.so.0.20 -# e.g. v20.0.1 => librte_stable.so.20.0.1, librte_experimental.so.0.2001 -# sonames => librte_stable.so.20.0, librte_experimental.so.0.200 +# e.g. v20.0.1 => librte_stable.so.20.0.1, librte_experimental.so.0.201 +# sonames => librte_stable.so.20.0, librte_experimental.so.0.20 abi_va = abi_version.split('.') stable_so_version = abi_va.length() == 2 ? abi_va[0] : abi_va[0] + '.' + abi_va[1] -experimental_abi_version = '0.' + ''.join(abi_va) -experimental_so_version = '0.' + ''.join(stable_so_version.split('.')) +experimental_abi_version = '0.' + ''.join([abi_va[0], abi_va[2]]) +experimental_so_version = '0.' + ''.join([abi_va[0]]) # extract all version information into the build configuration dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())
mk/rte.lib.mk +2 -2
@@ -15,8 +15,8 @@ LIBABIVER ?= $(shell cat $(RTE_SRCDIR)/ABI_VERSION) SOVER := $(basename $(LIBABIVER)) ifeq ($(shell grep -s "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),) # EXPERIMENTAL ABI is versioned as 0.major+minor, e.g. 0.201 for 20.1 ABI -LIBABIVER := 0.$(shell echo $(LIBABIVER) | tr -d '.') -SOVER := 0.$(shell echo $(SOVER) | tr -d '.') +LIBABIVER := 0.$(shell echo $(LIBABIVER) | cut -d '.' -f1,3 | tr -d '.') +SOVER := 0.$(shell echo $(SOVER) | cut -d '.' -f1) endif ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
Signature · 1 line
2.25.0
Re: [dpdk-dev] [PATCH] build: fix soname for experimental libraries
Quoted 37 lines · Thomas Monjalon
Because of an original mistake in ABI numbering, and a temporary workaround for ABI 20,
for experimental libs, numbering would lead to considerABI 20.1 > ABI 21.0Before this patch:
DPDK 19.11: ABI version 0.200 and soname 0.20 DPDK 20.02: ABI version 0.2001 and soname 0.201 Numbers are increasing, that's fine.
For the next major ABI, back to normal numbering:
DPDK 20.11: ABI version 0.210 and soname 0.21 Numbers are decreasing!After this patch:
DPDK 19.11: ABI version 0.200 and soname 0.20 DPDK 20.02: ABI version 0.201 and soname 0.20 DPDK 20.11: ABI version 0.210 and soname 0.21
Fixes f26c2b39b271 ("build: fix soname info for 19.11 compatibility")Signed-off-by Thomas Monjalon <[email protected]>--- config/meson.build | 8 ++++---- mk/rte.lib.mk | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)config/meson.build +0
-1@@ -27,12 +27,12 @@ abi_version = run_command(find_program('cat', 'more'), # and the filename suffix as 0.majorminor versions, # e.g. v20.1 => librte_stable.so.20.1, librte_experimental.so.0.201 # sonames => librte_stable.so.20, librte_experimental.so.0.20 -# e.g. v20.0.1 => librte_stable.so.20.0.1, librte_experimental.so.0.2001
config/meson.build abi_version = run_command(find_program('cat', 'more'), · line 36
Quoted 10 lines
config/meson.build +4
-3-# sonames => librte_stable.so.20.0, librte_experimental.so.0.200 +# e.g. v20.0.1 => librte_stable.so.20.0.1, librte_experimental.so.0.201 +# sonames => librte_stable.so.20.0, librte_experimental.so.0.20 abi_va = abi_version.split('.') stable_so_version = abi_va.length() == 2 ? abi_va[0] : abi_va[0] + '.' + abi_va[1] -experimental_abi_version = '0.' + ''.join(abi_va) -experimental_so_version = '0.' + ''.join(stable_so_version.split('.')) +experimental_abi_version = '0.' + ''.join([abi_va[0], abi_va[2]]) +experimental_so_version = '0.' + ''.join([abi_va[0]])
My concern about this is that it will break, or rather need to be changed again for the 20.11 release. While I see the numbering as not-ideal in terms of version numbers, the existing scheme was originally designed to work with either 3-digit or 2-digit version numbers.
/Bruce
Re: [dpdk-dev] [PATCH] build: fix soname for experimental libraries
18/02/2020 10:40, Bruce Richardson:
Quoted 45 lines · Thomas Monjalon
Quoted 44 lines
Because of an original mistake in ABI numbering, and a temporary workaround for ABI 20,
for experimental libs, numbering would lead to considerABI 20.1 > ABI 21.0Before this patch:
DPDK 19.11: ABI version 0.200 and soname 0.20 DPDK 20.02: ABI version 0.2001 and soname 0.201 Numbers are increasing, that's fine.
For the next major ABI, back to normal numbering:
DPDK 20.11: ABI version 0.210 and soname 0.21 Numbers are decreasing!After this patch:
DPDK 19.11: ABI version 0.200 and soname 0.20 DPDK 20.02: ABI version 0.201 and soname 0.20 DPDK 20.11: ABI version 0.210 and soname 0.21
Fixes f26c2b39b271 ("build: fix soname info for 19.11 compatibility")Signed-off-by Thomas Monjalon <[email protected]>--- config/meson.build | 8 ++++---- mk/rte.lib.mk | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)config/meson.build +2
-4@@ -27,12 +27,12 @@ abi_version = run_command(find_program('cat', 'more'), # and the filename suffix as 0.majorminor versions, # e.g. v20.1 => librte_stable.so.20.1, librte_experimental.so.0.201 # sonames => librte_stable.so.20, librte_experimental.so.0.20 -# e.g. v20.0.1 => librte_stable.so.20.0.1, librte_experimental.so.0.2001 -# sonames => librte_stable.so.20.0, librte_experimental.so.0.200 +# e.g. v20.0.1 => librte_stable.so.20.0.1, librte_experimental.so.0.201 +# sonames => librte_stable.so.20.0, librte_experimental.so.0.20 abi_va = abi_version.split('.') stable_so_version = abi_va.length() == 2 ? abi_va[0] : abi_va[0] + '.' + abi_va[1] -experimental_abi_version = '0.' + ''.join(abi_va) -experimental_so_version = '0.' + ''.join(stable_so_version.split('.'))
Quoted 8 lines
config/meson.build abi_version = run_command(find_program('cat', 'more'), · line 36
Quoted 3 lines
config/meson.build +2
-0+experimental_abi_version = '0.' + ''.join([abi_va[0], abi_va[2]]) +experimental_so_version = '0.' + ''.join([abi_va[0]])My concern about this is that it will break, or rather need to be changed again for the 20.11 release. While I see the numbering as not-ideal in terms of version numbers, the existing scheme was originally designed to work with either 3-digit or 2-digit version numbers.
It could be improved to work with 2-digit too.
Quoted 14 lines · Thomas Monjalon
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
/Bruce
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
Quoted 25 lines · Thomas Monjalon
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
Quoted 7 lines
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
I don't understand. Why would we change the ABI_VERSION at all in an LTS release at all? This operation is meant to take an an experimental API and mark it as stable by promoting its version number to the next major releases number. As such, in the LTS release, we should keep the soname the same, as there should be no other ABI changes in the promoted API.
Neil
Quoted 2 lines
19/02/2020 12:43, Neil Horman:
Quoted 30 lines · Thomas Monjalon
Quoted 29 lines
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Quoted 8 lines
Quoted 3 lines
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
I don't understand. Why would we change the
ABI_VERSIONat all in an LTS release at all? This operation is meant to take an an experimental API and mark it as stable by promoting its version number to the next major releases number. As such, in the LTS release, we should keep the soname the same, as there should be no other ABI changes in the promoted API.
The library version number is updated because we add new symbols.
Quoted 34 lines · Thomas Monjalon
19/02/2020 12:43, Neil Horman:
Quoted 33 lines · Thomas Monjalon
Quoted 32 lines
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
Quoted 9 lines
Quoted 5 lines
I don't understand. Why would we change the
ABI_VERSIONat all in an LTS release at all? This operation is meant to take an an experimental API and mark it as stable by promoting its version number to the next major releases number. As such, in the LTS release, we should keep the soname the same, as there should be no other ABI changes in the promoted API.The library version number is updated because we add new symbols.
So while experimental library version numbers are not "important".
I do agree with Thomas they should be sane, increase and should have a consistent format.
Should we always just pad them to 4 places as the simple solution? i.e.
DPDK 19.11 ... 0.20 (needs to remain 0.20).
DPDK 20.02 ... 0.2001
DPDK 20.11 ... 0.2100
DPDK 21.02 ... 0.2101
Make sense?
Ray K
19/02/2020 14:50, Ray Kinsella:
Quoted 48 lines · Thomas Monjalon
Quoted 34 lines
19/02/2020 12:43, Neil Horman:
Quoted 33 lines · Thomas Monjalon
Quoted 32 lines
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
Quoted 9 lines
Quoted 5 lines
I don't understand. Why would we change the
ABI_VERSIONat all in an LTS release at all? This operation is meant to take an an experimental API and mark it as stable by promoting its version number to the next major releases number. As such, in the LTS release, we should keep the soname the same, as there should be no other ABI changes in the promoted API.The library version number is updated because we add new symbols.
So while experimental library version numbers are not "important".
I do agree with Thomas they should be sane, increase and should have a consistent format.
Quoted 7 lines
Should we always just pad them to 4 places as the simple solution? i.e.
DPDK 19.11 ... 0.20 (needs to remain 0.20).
DPDK 20.02 ... 0.2001
DPDK 20.11 ... 0.2100
DPDK 21.02 ... 0.2101
A patch from Ferruh got merged.
It is adding a dot to keep versioning consistent.
Marking this patch as rejected.
Quoted 57 lines · Thomas Monjalon
19/02/2020 14:50, Ray Kinsella:
Quoted 48 lines · Thomas Monjalon
Quoted 34 lines
19/02/2020 12:43, Neil Horman:
Quoted 33 lines · Thomas Monjalon
Quoted 32 lines
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
Quoted 9 lines
Quoted 5 lines
I don't understand. Why would we change the
ABI_VERSIONat all in an LTS release at all? This operation is meant to take an an experimental API and mark it as stable by promoting its version number to the next major releases number. As such, in the LTS release, we should keep the soname the same, as there should be no other ABI changes in the promoted API.The library version number is updated because we add new symbols.
So while experimental library version numbers are not "important".
I do agree with Thomas they should be sane, increase and should have a consistent format.Quoted 7 lines
Should we always just pad them to 4 places as the simple solution? i.e.
DPDK 19.11 ... 0.20 (needs to remain 0.20).
DPDK 20.02 ... 0.2001
DPDK 20.11 ... 0.2100
DPDK 21.02 ... 0.2101
Quoted 5 lines
A patch from Ferruh got merged.
It is adding a dot to keep versioning consistent.Marking this patch as rejected.
Ferruh's was a better solution.
Quoted 34 lines · Thomas Monjalon
19/02/2020 12:43, Neil Horman:
Quoted 33 lines · Thomas Monjalon
Quoted 32 lines
18/02/2020 10:42, Bruce Richardson:
Quoted 15 lines · Thomas Monjalon
Quoted 14 lines
Hi,
I would like to remind everybody our mistake when defining ABI versions. It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental libraries.
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI and use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
Quoted 8 lines
Quoted 5 lines
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
Quoted 7 lines
Quoted 5 lines
I don't understand. Why would we change the
ABI_VERSIONat all in an LTS release at all? This operation is meant to take an an experimental API and mark it as stable by promoting its version number to the next major releases number. As such, in the LTS release, we should keep the soname the same, as there should be no other ABI changes in the promoted API.The library version number is updated because we add new symbols.
But thats a matter of policy (and possibly build mechanics). Not saying agree with this approach necessecarily (as I've not fully thought it through), but we could make room in the policy for this eventuality.
Neil
Quoted 3 lines
Quoted 40 lines
-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Tuesday 18 February 2020 09:50
To: Richardson, Bruce <[email protected]>
Cc: Kinsella, Ray <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: ABI version of experimental libraries18/02/2020 10:42, Bruce Richardson:
Quoted 4 lines · Thomas Monjalon
Quoted 3 lines
Hi,
I would like to remind everybody our mistake when defining ABI
versions.
Quoted 4 lines
Quoted 4 lines
It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental
libraries.
Quoted 2 lines
Quoted 2 lines
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In
DPDK
Quoted 2 lines
Quoted 2 lines
20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI
and
Quoted 11 lines
Quoted 8 lines
use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
Quoted 7 lines
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
So while experimental library version numbers are not "important".
I do agree with Thomas they should be sane, increase and should have a consistent format.
Should we always pad them to 4 places?
i.e.
DPDK 19.11 ... 0.20 (needs to remain 0.20).
DPDK 20.02 ... 0.2001
DPDK 20.11 ... 0.2100
DPDK 21.02 ... 0.2101
Make sense?
Ray K
Quoted 54 lines · Ray
Quoted 40 lines
-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Tuesday 18 February 2020 09:50
To: Richardson, Bruce <[email protected]>
Cc: Kinsella, Ray <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: ABI version of experimental libraries18/02/2020 10:42, Bruce Richardson:
Quoted 4 lines · Thomas Monjalon
Quoted 3 lines
Hi,
I would like to remind everybody our mistake when defining ABI
versions.
Quoted 4 lines
Quoted 4 lines
It has been "fixed" in this commit:
http://git.dpdk.org/dpdk/commit/?id=f26c2b39Please let's think about the consequence for the experimental
libraries.
Quoted 2 lines
Quoted 2 lines
In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In
DPDK
Quoted 2 lines
Quoted 2 lines
20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are increasing, that's fine. When we'll switch to the new major ABI
and
Quoted 11 lines
Quoted 8 lines
use a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 with soname 0.21 Numbers are dropping.
In short, for experimental libs, ABI 20.1 > ABI 21.0
Are we OK with this or do we prefer reverting to normal numbering for experimental libraries in DPDK 20.02?
Personally, I would not be too concerned about the verions of experimental libs, so long as they don't conflict across versions and have some similarity to the major ABI version for the release.
Quoted 7 lines
You think sorting of the version numbers is not important? If we don't care comparing experimental version numbers, then OK, let's drop this patch. But please we need a small vote.
Note: there would be no problem if we did not vote for having a special numbering for pure experimental libraries (I am still against).
So while experimental library version numbers are not "important".
I do agree with Thomas they should be sane, increase and should have a consistent format.Should we always pad them to 4 places?
i.e.
Quoted 7 lines
DPDK 19.11 ... 0.20 (needs to remain 0.20).
DPDK 20.02 ... 0.2001
DPDK 20.11 ... 0.2100
DPDK 21.02 ... 0.2101Make sense?
What about following:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211
This let us turn back to sane versions when soname fixed in 20.11.
Also I think for experimental libraries soname should NOT be same in minor versions, otherwise it can create false impression that it is ABI compatible between two minor versions.
I will reply the patch to this email.
PATCH 1/1 build: fix experimental library versioning
The problem occurred when workaround that makes soname two digits applied. With this change for the ABI version "20.0.1" the experimental library version become ".so.2001".
After workaround removed in ABI version 21.0, the experimental library version will become ".so.210".
"2001" is bigger value than "201" although it is a previous version of the library version, this can break the version comparisons.
To fix this, introducing a temporary sub level versioning for the experimental libraries, so that minor version comparison will continue to work.
After change experimental libraries will follow below versioning:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211
Note: After workaround removed in DPDK 20.11 and soname switch back to single digit this patch won't work and needs to be updated.
---
Cc: Thomas Monjalon <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
--- config/meson.build | 4 ++-- mk/rte.lib.mk | 8 +++++--- 2 files changed, 7 insertions(+), 5 deletions(-)
config/meson.build +2 -2
@@ -31,8 +31,8 @@ abi_version = run_command(find_program('cat', 'more'), # sonames => librte_stable.so.20.0, librte_experimental.so.0.200 abi_va = abi_version.split('.') stable_so_version = abi_va.length() == 2 ? abi_va[0] : abi_va[0] + '.' + abi_va[1] -experimental_abi_version = '0.' + ''.join(abi_va) -experimental_so_version = '0.' + ''.join(stable_so_version.split('.')) +experimental_abi_version = '0.' + abi_va[0] + abi_va[1] + '.' + abi_va[2] +experimental_so_version = experimental_abi_version # extract all version information into the build configuration dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())
mk/rte.lib.mk +5 -3
@@ -15,8 +15,8 @@ LIBABIVER ?= $(shell cat $(RTE_SRCDIR)/ABI_VERSION) SOVER := $(basename $(LIBABIVER)) ifeq ($(shell grep -s "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),) # EXPERIMENTAL ABI is versioned as 0.major+minor, e.g. 0.201 for 20.1 ABI -LIBABIVER := 0.$(shell echo $(LIBABIVER) | tr -d '.') -SOVER := 0.$(shell echo $(SOVER) | tr -d '.') +LIBABIVER := 0.$(shell echo $(LIBABIVER) | awk 'BEGIN { FS="." }; { print $$1$$2"."$$3 }') +SOVER := $(LIBABIVER) endif ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
@@ -135,7 +135,9 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB) $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/') - $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so.$(SOVER)/') + $(Q)if [ $(SOVER) != $(LIBABIVER) ]; then \ + ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so.$(SOVER)/') ; \ + fi endif #
Signature · 1 line
2.24.1
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
Quoted 30 lines · Ferruh Yigit
The problem occurred when workaround that makes soname two digits applied. With this change for the ABI version "20.0.1" the experimental
library version become ".so.2001".
After workaround removed in ABI version 21.0, the experimental library
version will become ".so.210".
"2001" is bigger value than "201" although it is a previous version of
the library version, this can break the version comparisons.To fix this, introducing a temporary sub level versioning for the experimental libraries, so that minor version comparison will continue
to work.After change experimental libraries will follow below versioning:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211Note: After workaround removed in DPDK 20.11 and soname switch back to
single digit this patch won't work and needs to be updated.
Quoted 5 lines
Fixes f26c2b39b271 ("build: fix soname info for 19.11compatibility")
Signed-off-by: Ferruh Yigit <
[email protected]
This solution looks like a good compromise to me. Thanks Ferruh.
Signature · 2 lines
Kind regards, Luca Boccassi
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
In reply to Ferruh YigitQuoted 22 lines · Ferruh Yigit
The problem occurred when workaround that makes soname two digits applied. With this change for the ABI version "20.0.1" the experimental library version become ".so.2001".
After workaround removed in ABI version 21.0, the experimental library version will become ".so.210".
"2001" is bigger value than "201" although it is a previous version of the library version, this can break the version comparisons.To fix this, introducing a temporary sub level versioning for the experimental libraries, so that minor version comparison will continue to work.
After change experimental libraries will follow below versioning:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211
Quoted 5 lines
Note: After workaround removed in DPDK 20.11 and soname switch back to single digit this patch won't work and needs to be updated.
Fixes f26c2b39b271 ("build: fix soname info for 19.11 compatibility")
Quoted 56 lines
Signed-off-by Ferruh Yigit <[email protected]>---
Cc: Thomas Monjalon <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]--- config/meson.build | 4 ++-- mk/rte.lib.mk | 8 +++++--- 2 files changed, 7 insertions(+), 5 deletions(-)config/meson.build +2
-2@@ -31,8 +31,8 @@ abi_version = run_command(find_program('cat', 'more'), # sonames => librte_stable.so.20.0, librte_experimental.so.0.200 abi_va = abi_version.split('.') stable_so_version = abi_va.length() == 2 ? abi_va[0] : abi_va[0] + '.' + abi_va[1] -experimental_abi_version = '0.' + ''.join(abi_va) -experimental_so_version = '0.' + ''.join(stable_so_version.split('.')) +experimental_abi_version = '0.' + abi_va[0] + abi_va[1] + '.' + abi_va[2] +experimental_so_version = experimental_abi_version # extract all version information into the build configuration dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())mk/rte.lib.mk +5
-3@@ -15,8 +15,8 @@ LIBABIVER ?= $(shell cat $(RTE_SRCDIR)/ABI_VERSION) SOVER := $(basename $(LIBABIVER)) ifeq ($(shell grep -s "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),) # EXPERIMENTAL ABI is versioned as 0.major+minor, e.g. 0.201 for 20.1 ABI -LIBABIVER := 0.$(shell echo $(LIBABIVER) | tr -d '.') -SOVER := 0.$(shell echo $(SOVER) | tr -d '.') +LIBABIVER := 0.$(shell echo $(LIBABIVER) | awk 'BEGIN { FS="." }; { print $$1$$2"."$$3 }') +SOVER := $(LIBABIVER) endif ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)@@ -135,7 +135,9 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB) $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/') - $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so.$(SOVER)/') + $(Q)if [ $(SOVER) != $(LIBABIVER) ]; then \ + ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so.$(SOVER)/') ; \ + fi endif #
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
In reply to Ferruh YigitQuoted 23 lines · Ferruh Yigit
The problem occurred when workaround that makes soname two digits applied. With this change for the ABI version "20.0.1" the experimental library version become ".so.2001".
After workaround removed in ABI version 21.0, the experimental library version will become ".so.210".
"2001" is bigger value than "201" although it is a previous version of the library version, this can break the version comparisons.To fix this, introducing a temporary sub level versioning for the experimental libraries, so that minor version comparison will continue to work.
After change experimental libraries will follow below versioning:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211
Quoted 6 lines
Note: After workaround removed in DPDK 20.11 and soname switch back to single digit this patch won't work and needs to be updated.
Fixes f26c2b39b271 ("build: fix soname info for 19.11 compatibility")Signed-off-by Ferruh Yigit <[email protected]>
The soname change breaks existing applications like testpmd (linked to various experimental libraries).
I have the full details if needed in a pastebin (v19.11, master, patch_applied).
$ LD_LIBRARY_PATH=$HOME/builds/x86_64-native-linux-gcc+shared+kmods/install/lib $HOME/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd: error while loading shared libraries: librte_flow_classify.so.0.200: cannot open shared object file: No such file or directory
libabigail reports this change as an error, so if it is intended, we need to bypass the check for those libraries.
Functions changes summary: 0 Removed, 0 Changed (2 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed (7 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
SONAME changed from 'librte_flow_classify.so.0.200' to 'librte_flow_classify.so.0.200.1'
Error: ABI issue reported for 'abidiff --suppr /home/dmarchan/dpdk/devtools/libabigail.abignore --no-added-syms
--headers-dir1 /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/include --headers-dir2 /home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/include /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/dump/librte_flow_classify.dump /home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/dump/librte_flow_classify.dump'
Signature · 1 line
David Marchand
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
Quoted 42 lines · David Marchand
Quoted 23 lines · Ferruh Yigit
The problem occurred when workaround that makes soname two digits applied. With this change for the ABI version "20.0.1" the experimental library version become ".so.2001".
After workaround removed in ABI version 21.0, the experimental library version will become ".so.210".
"2001" is bigger value than "201" although it is a previous version of the library version, this can break the version comparisons.To fix this, introducing a temporary sub level versioning for the experimental libraries, so that minor version comparison will continue to work.
After change experimental libraries will follow below versioning:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211Quoted 6 lines
Note: After workaround removed in DPDK 20.11 and soname switch back to single digit this patch won't work and needs to be updated.
Fixes f26c2b39b271 ("build: fix soname info for 19.11 compatibility")Signed-off-by Ferruh Yigit <[email protected]>The soname change breaks existing applications like testpmd (linked to various experimental libraries).
I have the full details if needed in a pastebin (v19.11, master,patch_applied).$ LD_LIBRARY_PATH=$HOME/builds/x86_64-native-linux-gcc+shared+kmods/install/lib $HOME/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd: error while loading shared libraries: librte_flow_classify.so.0.200: cannot open shared object file: No such file or directory
Quoted 2 lines
libabigail reports this change as an error, so if it is intended, we need to bypass the check for those libraries.
soname change was intended, we don't provide any ABI compatibility in the experimental libraries, keeping same soname may mislead as if we do.
The impact of it is, any application linked against experimental library will need to recompile in new release.
Can we add exception to the the libabigail for experimental libraries?
Quoted 19 lines
Functions changes summary: 0 Removed, 0 Changed (2 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed (7 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
SONAME changed from 'librte_flow_classify.so.0.200' to 'librte_flow_classify.so.0.200.1'
Error: ABI issue reported for 'abidiff --suppr/home/dmarchan/dpdk/devtools/libabigail.abignore--no-added-syms
--headers-dir1/home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/include--headers-dir2/home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/include/home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/dump/librte_flow_classify.dump/home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/dump/librte_flow_classify.dump'
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
In reply to Ferruh YigitQuoted 23 lines · Ferruh Yigit
The problem occurred when workaround that makes soname two digits applied. With this change for the ABI version "20.0.1" the experimental library version become ".so.2001".
After workaround removed in ABI version 21.0, the experimental library version will become ".so.210".
"2001" is bigger value than "201" although it is a previous version of the library version, this can break the version comparisons.To fix this, introducing a temporary sub level versioning for the experimental libraries, so that minor version comparison will continue to work.
After change experimental libraries will follow below versioning:
DPDK version ABI version soname library name ------------ ----------- ------ ------------ DPDK 19.11 20.0 .so.0.200 .so.0.200 DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1 DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2 DPDK 20.11 21.0 .so.0.210 .so.0.210 DPDK 21.02 21.1 .so.0.211 .so.0.211
Quoted 6 lines
Note: After workaround removed in DPDK 20.11 and soname switch back to single digit this patch won't work and needs to be updated.
Fixes f26c2b39b271 ("build: fix soname info for 19.11 compatibility")Signed-off-by Ferruh Yigit <[email protected]>
Applied.
Signature · 1 line
David Marchand