[v2] ci: build and use libabigail 1.6
Checks
Commit Message
libabigail 1.2 (at least) reports changes in 'const' property as an ABI
breakage [1].
This was fixed upstream in libabigail 1.4 [2], and a bug has been opened
in launchpad [3].
But for now, build and use the last version 1.6 so that the ABI checks
can be kept.
1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242
2: https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commitdiff;h=215b7eb4fe8b
3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changelog since v1:
- keep extra_packages in ABI checks jobs,
- fix configure step,
---
.ci/linux-build.sh | 23 +++++++++++++++++++++++
.travis.yml | 8 +++++++-
2 files changed, 30 insertions(+), 1 deletion(-)
Comments
18/02/2020 15:29, David Marchand:
> libabigail 1.2 (at least) reports changes in 'const' property as an ABI
> breakage [1].
> This was fixed upstream in libabigail 1.4 [2], and a bug has been opened
> in launchpad [3].
>
> But for now, build and use the last version 1.6 so that the ABI checks
> can be kept.
>
> 1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242
> 2: https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commitdiff;h=215b7eb4fe8b
> 3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
I suggest few improvements below:
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> if [ "$ABI_CHECKS" = "1" ]; then
What do you think about moving the libabigail install in a function?
We could justify this with a comment about installing the latest version.
> + LIBABIGAIL_REPO=${LIBABIGAIL_REPO:-https://sourceware.org/git/libabigail.git}
> + LIBABIGAIL_VERSION=${LIBABIGAIL_VERSION:-libabigail-1.6}
> +
> + if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
> + rm -rf libabigail
> + # if we change libabigail, invalidate existing abi cache
> + rm -rf reference
> + fi
> +
> + if [ ! -d libabigail ]; then
> + git clone --single-branch -b $LIBABIGAIL_VERSION $LIBABIGAIL_REPO libabigail/src
Why not using the tarball?
http://mirrors.kernel.org/sourceware/libabigail/libabigail-1.6.tar.gz
> + cd libabigail/src && autoreconf -i && cd -
> + instdir=$(pwd)/libabigail
> + mkdir libabigail/src/build
> + cd libabigail/src/build && ../configure --prefix=$instdir && cd -
> + make -C libabigail/src/build all install
> +
> + rm -rf libabigail/src
> + echo $LIBABIGAIL_VERSION > libabigail/VERSION
> + fi
> +
> + export PATH=$(pwd)/libabigail/bin:$PATH
On Tue, Feb 18, 2020 at 4:46 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 18/02/2020 15:29, David Marchand:
> > libabigail 1.2 (at least) reports changes in 'const' property as an ABI
> > breakage [1].
> > This was fixed upstream in libabigail 1.4 [2], and a bug has been opened
> > in launchpad [3].
> >
> > But for now, build and use the last version 1.6 so that the ABI checks
> > can be kept.
> >
> > 1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242
> > 2: https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commitdiff;h=215b7eb4fe8b
> > 3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>
> I suggest few improvements below:
>
> > --- a/.ci/linux-build.sh
> > +++ b/.ci/linux-build.sh
> > if [ "$ABI_CHECKS" = "1" ]; then
>
> What do you think about moving the libabigail install in a function?
No strong opinion, we had everything inline so far.
>
> We could justify this with a comment about installing the latest version.
>
> > + LIBABIGAIL_REPO=${LIBABIGAIL_REPO:-https://sourceware.org/git/libabigail.git}
> > + LIBABIGAIL_VERSION=${LIBABIGAIL_VERSION:-libabigail-1.6}
> > +
> > + if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
> > + rm -rf libabigail
> > + # if we change libabigail, invalidate existing abi cache
> > + rm -rf reference
> > + fi
> > +
> > + if [ ! -d libabigail ]; then
> > + git clone --single-branch -b $LIBABIGAIL_VERSION $LIBABIGAIL_REPO libabigail/src
>
> Why not using the tarball?
> http://mirrors.kernel.org/sourceware/libabigail/libabigail-1.6.tar.gz
No good reason "now".
I was first bitten by a reference to redhat-hardened-ld in some
libtool script in the tarball (/me looks in Dodji direction).
I then considered switching to different versions of libabigail by
just setting the LIBABIGAIL_VERSION env variable from .travis.yml.
I ended up with the current latest version which is also what is in
Ubuntu latest releases.
The tarball is smaller than a git clone, so best to use it.
v3 incoming.
Hello,
David Marchand <david.marchand@redhat.com> writes:
>> > + LIBABIGAIL_REPO=${LIBABIGAIL_REPO:-https://sourceware.org/git/libabigail.git}
>> > + LIBABIGAIL_VERSION=${LIBABIGAIL_VERSION:-libabigail-1.6}
>> > +
>> > + if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
>> > + rm -rf libabigail
>> > + # if we change libabigail, invalidate existing abi cache
>> > + rm -rf reference
>> > + fi
>> > +
>> > + if [ ! -d libabigail ]; then
>> > + git clone --single-branch -b $LIBABIGAIL_VERSION $LIBABIGAIL_REPO libabigail/src
>>
>> Why not using the tarball?
>> http://mirrors.kernel.org/sourceware/libabigail/libabigail-1.6.tar.gz
>
> No good reason "now".
>
> I was first bitten by a reference to redhat-hardened-ld in some
> libtool script in the tarball (/me looks in Dodji direction).
> I then considered switching to different versions of libabigail by
> just setting the LIBABIGAIL_VERSION env variable from .travis.yml.
> I ended up with the current latest version which is also what is in
> Ubuntu latest releases.
I think either way (distro package, tarball and git) has some benefits
and drawbacks.
I think one benefit of /being able/ to use the code from git is for
cases where you guys need some new features (and we tend to continuously
add fixes/functionalities to the git repository) that is available in
git only for now. Hopefully, with time, you'll only need to use the
distro package.
FWIW, I like the fact that your setup lets you choose between the distro
package, the tarball or the git code. That's powerful.
Cheers,
@@ -38,6 +38,29 @@ if [ "$AARCH64" != "1" ]; then
fi
if [ "$ABI_CHECKS" = "1" ]; then
+ LIBABIGAIL_REPO=${LIBABIGAIL_REPO:-https://sourceware.org/git/libabigail.git}
+ LIBABIGAIL_VERSION=${LIBABIGAIL_VERSION:-libabigail-1.6}
+
+ if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
+ rm -rf libabigail
+ # if we change libabigail, invalidate existing abi cache
+ rm -rf reference
+ fi
+
+ if [ ! -d libabigail ]; then
+ git clone --single-branch -b $LIBABIGAIL_VERSION $LIBABIGAIL_REPO libabigail/src
+ cd libabigail/src && autoreconf -i && cd -
+ instdir=$(pwd)/libabigail
+ mkdir libabigail/src/build
+ cd libabigail/src/build && ../configure --prefix=$instdir && cd -
+ make -C libabigail/src/build all install
+
+ rm -rf libabigail/src
+ echo $LIBABIGAIL_VERSION > libabigail/VERSION
+ fi
+
+ export PATH=$(pwd)/libabigail/bin:$PATH
+
REF_GIT_REPO=${REF_GIT_REPO:-https://dpdk.org/git/dpdk}
REF_GIT_TAG=${REF_GIT_TAG:-v19.11}
@@ -2,6 +2,7 @@ language: c
cache:
ccache: true
directories:
+ - libabigail
- reference
compiler:
- gcc
@@ -24,7 +25,10 @@ aarch64_packages: &aarch64_packages
extra_packages: &extra_packages
- *required_packages
- - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4, abigail-tools]
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+
+libabigail_build_packages: &libabigail_build_packages
+ - [autoconf, automake, libtool, pkg-config, libxml2-dev, libdw-dev]
build_32b_packages: &build_32b_packages
- *required_packages
@@ -160,6 +164,7 @@ matrix:
apt:
packages:
- *extra_packages
+ - *libabigail_build_packages
- env: DEF_LIB="shared" EXTRA_PACKAGES=1 ABI_CHECKS=1
arch: arm64
compiler: gcc
@@ -167,5 +172,6 @@ matrix:
apt:
packages:
- *extra_packages
+ - *libabigail_build_packages
script: ./.ci/${TRAVIS_OS_NAME}-build.sh