[OE-core] [PATCH] alsa-lib:upgrade 1.1.9 -> 1.2.1.1

[Tanu Kaskinen]

On Wed, 2019-11-20 at 12:16 +0100, Alexander Kanavin wrote:
> On Wed, 20 Nov 2019 at 06:17, Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
> wrote:
> 
> > +From f419276a716daf8d98846b3df50995e5ac030134 Mon Sep 17 00:00:00 2001
> > +From: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
> > +Date: Wed, 20 Nov 2019 11:24:17 +0800
> > +Subject: [PATCH] Fix problem with libtool not found
> > +
> > +Upstream-Status: Inappropriate
> > 
> 
> Why inappropriate? To me this seems like a real problem and should be
> submitted upstream.

I planned to submit this patch to upstream on behalf of Zang, but while
investigating what the root cause for the failure really is, I found
that this really is OE specific.

Upstream for some reason (not documented in the commit message, and the
main point of the commit was something else entirely[1]) added this to
the end of configure.ac:

dnl Taken from https://wiki.debian.org/RpathIssue
case $host in
   *-*-linux-gnu)
   AC_MSG_RESULT([Fixing libtool for -rpath problems.])
   sed < libtool > libtool-2 \
     's/^hardcode_libdir_flag_spec.*$'/'hardcode_libdir_flag_spec=" -D__LIBTOOL_IS_A_FOOL__ "/'
   mv libtool-2 libtool
   chmod 755 libtool
 ;;
esac

If I understand the referenced Debian wiki page correctly, this is only
useful if the tarball ships libtool older than 1.5.2 (released 2004-01-
05). That is, this addition seems completely useless to me. Probably
I'm missing something.

The configure script fails, because it tries to modify the libtool
script in the build directory, but the libtool script doesn't exist.
And it doesn't exist, because OE renames it to ${host_alias}-libtool
(e.g. x86_64-oe-linux-libtool).

I'm not sure where the libtool script in the build directory comes
from. Is it copied from the tarball's libtool script, or does it come
from the libtool package? (Bitbake seems to run autoreconf and
libtoolize, if that's relevant.) If the script comes from the libtool
package, then modifying the script in the source directory (like Zang's
patch does) is useless, since that script isn't used at all. If the
tarball's libtool script is used, then Zang's patch still doesn't do
what it's expected to do, because the script modification is the very
last thing the configure script does, and the build directory's libtool
script has already been created by then, so modifying the source
directory's libtool script happens too late.

I'll have to ask upstream if the strange configure.ac addition could be
just removed. If it for some reason won't be removed, then an OE
specific patch is needed. Either configure.ac needs to be modified to
operate on ${host_alias}-libtool, or I can simply remove the libtool
modification part, because OE hasn't needed that in the past, and I
can't see how it would be needed now.

[1] https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=75d393a563efb578c79364a277087c6326267f52;hp=1f37ba2a2b1c07c04de1c368cd4943f712cccfa5

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk