GNU bug report logs - #10231
libtool.m4 makes the wrong shell (dash) run libtool

Previous Next

To reply to this bug, email your comments to 10231 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
To: bug-libtool <at> gnu.org
Subject: libtool.m4 makes the wrong shell (dash) run libtool
Date: Tue, 06 Dec 2011 12:59:52 +0100

This is an old bug by now, but the reports I've seen do not seem to
get at all of it.

libtool.m4:LT_INIT says LIBTOOL='$(SHELL) $(top_builddir)/libtool'.
Gnu Make exports SHELL=/bin/sh.  Maybe other Makes too, I do not know.

Thus even when a package is configured and built with the same $SHELL,
the libtool script can get run by another shell than it was built for.
This breaks when libtool is built as a bash script using '+=', but
$(SHELL) does not support '+='.  In my case: Ubuntu's /bin/sh = dash.

Either the LIBTOOL= line should lose $(SHELL) so the #!<shell> line in
the libtool script takes effect, or it should use e.g. $(LT_SHELL)
which would be set to the shell which libtool was built for, or
libtool should exec itself with its desired shell.  Users should not
have to set CONFIG_SHELL=/bin/sh.

This applies to at least libtoolize 2.4.2 and Ubuntu's patched 2.4.
I'm using aclocal 1.11.1, autoconf 2.68.


Here is a minimized example:

mkdir foo foo/m4
cd    foo
echo 'int main() {return 0;}'	> foo.c

cat <<'EOF'			> Makefile.in
top_builddir = @top_builddir@
foo.o:; @LIBTOOL@ --mode=compile @CC@ -c foo.c
EOF

cat <<'EOF'			> configure.ac
AC_INIT([foo])
AC_CONFIG_AUX_DIR([m4])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_CC
LT_INIT([disable-shared])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

libtoolize --copy --install --quiet; aclocal -I m4; autoconf
./configure --quiet
cat Makefile; echo "libtool head == `head -1 libtool`"
make

Output:

top_builddir = .
foo.o:; $(SHELL) $(top_builddir)/libtool --mode=compile gcc -c foo.c
libtool head == #! /bin/bash
/bin/sh ./libtool --mode=compile gcc -c foo.c
eval: 1: base_compile+= gcc: not found
eval: 1: base_compile+= -c: not found
libtool: compile: you must specify a compilation command
libtool: compile: Try `libtool --help --mode=compile' for more information.
make: *** [foo.o] Error 1


Any advise as to what to do (other than staying with libtool 1.5)?
For now I use the simplest fix, removing $(SHELL).  Or should
Makefile.in be using something else than @LIBTOOL@?

Message #8 received at 10231 <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
Cc: 10231 <at> debbugs.gnu.org
Subject: Re: bug#10231: libtool.m4 makes the wrong shell (dash) run libtool
Date: Tue, 06 Dec 2011 21:05:16 -0600

On 12/06/2011 05:59 AM, Hallvard B Furuseth wrote:
> This is an old bug by now, but the reports I've seen do not seem to
> get at all of it.
>
> libtool.m4:LT_INIT says LIBTOOL='$(SHELL) $(top_builddir)/libtool'.
> Gnu Make exports SHELL=/bin/sh.  Maybe other Makes too, I do not know.
>
> Any advise as to what to do (other than staying with libtool 1.5)?
> For now I use the simplest fix, removing $(SHELL).  Or should
> Makefile.in be using something else than @LIBTOOL@?

Hi,

Thanks for the report.

Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it 
will cause problems on windows though?

If it's a problem, we can AC_SUBST(LT_SHELL) and use that (which will 
cause problems for people not using automake, like yourself).

Peter

Message #11 received at 10231 <at> debbugs.gnu.org (full text, mbox):

From: Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: 10231 <at> debbugs.gnu.org
Subject: Re: bug#10231: libtool.m4 makes the wrong shell (dash) run libtool
Date: Wed, 7 Dec 2011 11:15:20 +0100

Peter O'Gorman writes:
> Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it 
> will cause problems on windows though?

Don't know.  Since this is for a Unix-style Makefile, I expect it
depends on Cygnus et al to compile system() and exec() in the Make
program into library calls which handle '#!'.

> If it's a problem, we can AC_SUBST(LT_SHELL) and use that (which will 
> cause problems for people not using automake, like yourself).

Eh, right.  Sounds like the shell should be inserted in the LIBTOOL
definition itself then, without going via an LT_SHELL.

Which in turn would prevent people from running libtool with another
shell if the current shell breaks, if there is any reason to do that.

-- 
Hallvard

Message #14 received at 10231 <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: 10231 <at> debbugs.gnu.org, Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
Subject: Re: bug#10231: libtool.m4 makes the wrong shell (dash) run libtool
Date: Wed, 07 Dec 2011 08:11:31 -0500

Peter O'Gorman wrote:
> 
> Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it
> will cause problems on windows though?
> 

I don't think it should matter.  Both Cygwin and MSYS have /bin/sh and
/usr/bin/sh.  Without a POSIX shell libtool is impossible anyway.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd/

Message #17 received at 10231 <at> debbugs.gnu.org (full text, mbox):

From: Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
To: Earnie <earnie <at> users.sourceforge.net>
Cc: 10231 <at> debbugs.gnu.org, Peter O'Gorman <peter <at> pogma.com>
Subject: Re: bug#10231: libtool.m4 makes the wrong shell (dash) run libtool
Date: Fri, 9 Dec 2011 16:55:44 +0100

Earnie writes:
> Peter O'Gorman wrote:
>> Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it
>> will cause problems on windows though?
> 
> I don't think it should matter.  Both Cygwin and MSYS have /bin/sh and
> /usr/bin/sh.  Without a POSIX shell libtool is impossible anyway.

Yeah, but the question is if Cygnus/MSYS ensure that when the Make
program invokes libtool it obeys the '#! <shell path>' line inside it.
Windows itself does not.  I assume yes, but I don't use Windows.

-- 
Hallvard

Message #20 received at 10231 <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
Cc: 10231 <at> debbugs.gnu.org, Peter O'Gorman <peter <at> pogma.com>
Subject: Re: bug#10231: libtool.m4 makes the wrong shell (dash) run libtool
Date: Fri, 09 Dec 2011 13:23:26 -0500

Hallvard B Furuseth wrote:
> Earnie writes:
>> Peter O'Gorman wrote:
>>> Removing $(SHELL) from LIBTOOL makes sense to me, I don't know if it
>>> will cause problems on windows though?
>>
>> I don't think it should matter.  Both Cygwin and MSYS have /bin/sh and
>> /usr/bin/sh.  Without a POSIX shell libtool is impossible anyway.
> 
> Yeah, but the question is if Cygnus/MSYS ensure that when the Make
> program invokes libtool it obeys the '#! <shell path>' line inside it.
> Windows itself does not.  I assume yes, but I don't use Windows.
> 

Yes they do.  It is a POSIX requirement.  And since Cygwin/MSYS are
emulating POSIX on Windows then it works as it should.

In Cygwin we have:
$ /bin/sh --version
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

In MSYS we have:
$ /bin/sh --version
GNU bash, version 3.1.17(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.

Executing in MSYS we have:
$ ./libtool --version
libtool (GNU libtool) 2.2.10
Written by Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, 1996

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ libtoolize --version
libtoolize (GNU libtool) 2.4
Written by Gary V. Vaughan <gary <at> gnu.org>, 2003

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd/

Message #23 received at 10231 <at> debbugs.gnu.org (full text, mbox):

From: Hallvard B Furuseth <h.b.furuseth <at> usit.uio.no>
To: 10231 <at> debbugs.gnu.org
Cc: Peter O'Gorman <peter <at> pogma.com>
Subject: Re: bug#10231: libtool.m4 makes the wrong shell (dash) run libtool
Date: Sat, 10 Dec 2011 16:45:37 +0100

Earnie writes:
>> Yeah, but the question is if Cygnus/MSYS ensure that when the Make
>> program invokes libtool it obeys the '#! <shell path>' line inside it.
>> (...)
> Yes they do.  (...)

Thanks.


BTW, I just noticed this in the GNU coding standards, 7.2.1 General
Conventions for Makefiles:

    "Every Makefile should contain this line:

      SHELL = /bin/sh

    to avoid trouble on systems where the `SHELL' variable might be
    inherited from the environment.  (This is never a problem with GNU
    `make'.)"

So Make programs differ in this, the current '$(SHELL) libtool' was
never supposed to be correct, and $CONFIG_SHELL concerns seem irrelevant.

-- 
Hallvard

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.