14/05/2020 19:15, Hemant Agrawal (OSS): > > On Thu, May 14, 2020 at 3:31 PM David Marchand > > <david.march...@redhat.com> wrote: > > > On Thu, May 14, 2020 at 2:39 PM Hemant Agrawal (OSS) > > > <hemant.agra...@oss.nxp.com> wrote: > > > > > > > > [Hemant] this is working fine for pmd_dpaa but not for pmd_dpaa2 > > > > > > > > I removed the filename_exp and introduced function based name > > > > Now the issue is the following warning SONAME changed from > > > > 'librte_pmd_dpaa2.so.20.0' to 'librte_pmd_dpaa2.so.0.200.2' > > > > > > > > The primary reason is that now pmd_dpaa2 has no symbol left for > > > > 20.0 section. > > > > Following is not helping. > > > > [suppress_file] > > > > soname_regexp = ^librte_pmd_dpaa2 so, it seems for now, the > > > > filename_exp is the only option > > > > > > That's interesting. > > > Because I wondered about this point when reviewing __rte_internal. > > > For components providing only internal symbols like components > > > providing only experimental symbols, the build framework will select a > > > soname with .0.200.x.
I will remind once again that I was against this rule. Distinguishing "stable or partially stable" and "completely non-stable" libraries is an useless complication. > > > Here, your dpaa2 driver was seen as a stable library so far. > > > Moving everything to internal changes this and the build framework > > > changes the soname to non stable. > > > > Looking at a v19.11 testpmd binary: > > $ readelf -d $HOME/abi/v19.11/build-gcc-shared/usr/local/bin/dpdk-testpmd > > |grep dpaa > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_bus_dpaa.so.20.0] > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_common_dpaax.so.20.0] > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_mempool_dpaa.so.20.0] > > 0x0000000000000001 (NEEDED) Shared library: > > [librte_pmd_dpaa.so.20.0] > > > > Changing the soname would break this. > > > > > You could keep an empty DPDK_20.0 block to avoid this and the soname > > > will be kept as is. > > [Hemant] Yes, I was thinking about it but missed to make this change while > sending patch. Will do it asap. > > > > We will have to maintain such soname for all dpaa libraries until 20.11. Thank you for maintaining the soname compatibility in v7. Now the question is: what to do in v20.11? This question will have to be voted in the Technical Board which voted the "pure experimental" versioning rule. We have 3 options: a) "Pure internal" libs are versioned as "stable" libs, while "pure experimental" libs have version 0.x. It looks inconsistent and non-sense. b) "Pure internal" libs are versioned as "pure experimental" libs: version 0.x. It makes "pure internal" libs version decreasing in 20.11. c) Forget about the different versioning scheme, i.e. increase 0.x versions to x as "stable" libs. Of course, I vote for option c.
