[v2] ci: build and use libabigail 1.6

  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(-)
  

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,