Re: [Audacity-devel] audacity trunk fails to build on Ubuntu

[Richard A. <ri...@au...>]

On Fri, 2010-10-15 at 15:51 +0100, Gale Andrews wrote:
> | From Ashton Alan Kemerling <ash...@gm...> 
> | Thu, 14 Oct 2010 14:40:01 -0500
> | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu
> > I'm still getting the exact same error for r10730 on Ubuntu 10.10 64
> > bit, libtool 2.2.6b
> 
> I tried doing some searching on "eval: 1: libtool_args+=: not found"
> and came up with this:
> http://www.mail-archive.com/bac...@li.../msg04127.html
> 
> which states
> 
> "freshly installed ubuntus link /bin/sh to /bin/dash. Seems that some 
>    scripts use bashisms."
> 
> But it doesn't help me.
It does help me replicate the problem however because I can now get the
error to happen here (after installing dash and linking it to /bin/sh).
This explains why it was looking increasingly like an Ubuntu-only
problem, and saves me trying to install Ubuntu to work out why.

> Anyway if just typing "bash" at the command prompt changes the shell, it 
> doesn't help me on Ubuntu 10.10 -  I still get  the  
> "eval: 1: libtool_args+=: not found",  then "syntax error in VERSION script".

It doesn't. The problem is really a hack in autoconf / configure which
is setting a variable into libtool which it shouldn't. By forcing
configure to use a specific shell the auto-detection is disabled and
things start working. So

CONFIG_SHELL=/bin/dash ./configure ; make

will work and let you build Audacity. More generally (for any
distribution where /bin/sh != /bin/bash) you can use

CONFIG_SHELL=/bin/sh ./configure ; make

which ensures that the shell which runs configure is also /bin/sh (via
the obvious mechanism). This only works provided that /bin/sh is smart
enough to run configure, but that includes most likely shells.

The bigger question is what about portaudio in particular makes it so
sensitive to what shell is used. Just running configure in the upstream
portaudio sources seems to work fine with /bin/sh == /bin/dash (as it
does with /bin/sh == /bin/bash) so at first glance it seems to be a
problem with something that Audacity is doing differently, or a local
patch we are carrying. The problem in the linked bug report seems to be
a "clever" hack in the specific project concerned, and there is nothing
like that in portaudio's configure.

Copying the command line from the Audacity configure script (i.e. the
way that portaudio-v19's configure is called) works fine, which suggests
that the problem is not with the arguments given (this also explicitly
runs the configure script with /bin/sh, which ought to stop the problem
happening).

The problem seems to be closely related however, because in portaudio's
makefile (in the Audacity source tree) I find
LIBTOOL = $(SHELL) $(top_builddir)/libtool
yet at the top of portaudio's libtool (same tree)
#! /bin/bash

If I amend the makefile to read
LIBTOOL = $(top_builddir)/libtool
then I can build fine (because libtool is allowed to choose it's own
shell). However the same mismatch exists in the upstream portaudio, and
that builds correctly. This is also not a permanent solution because
Makefile is generated from Makefile.in, where it just says 
LIBTOOL = @LIBTOOL@
so the value of the libtool substitution seems to be entirely in the
hands of config.status when it processes Makefile.in

This seems to be leading somewhere: portaudio in upstream is still using
old libtool 1.5, which for all it's other weaknesses is (apparently)
immune to this bug, where as Audacity has upgraded to use libtool 2.2.x
everywhere (largely because things didn't work on OS X with the old
libtool), where this bug does happen.

If I fully upgrade portaudio sources to libtool 2.2.10 (that is, remove
the libtool script, remove all aclocal.m4 files, run libtoolize --copy
--force, run aclocal, run autoconf) then I can reproduce the Audacity
problem. Failure to do all of the above will just cause libtool version
mis-matches as portaudio doesn't carry the libtool .m4 files in it's
source tree, but does seem to carry aclocal.m4 files (which is
considered a bad idea at the very least).

So we have a problem which is definitely present with autoconf-2.65 and
libtool-2.2.10 (on the system which updates the sources, i.e. mine) when
configured on a system with /bin/sh != /bin/bash. It's not yet clear if
this is general (i.e. if I re-do another libtool-based library will I
break it?) or not.

I will try and delve further when I get the time, as google doesn't seem
to have anything directly relevant.

Richard