bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rep-gtk and librep-dev bash/dash libtool breakage


From: Ralf Wildenhues
Subject: Re: rep-gtk and librep-dev bash/dash libtool breakage
Date: Thu, 14 Oct 2010 20:28:39 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

tags 570723 + upstream
thanks

[ http://bugs.debian.org/570723 ]

* Tim Retout wrote on Thu, Oct 14, 2010 at 10:26:00AM CEST:
>  2010 09:11, Ralf Wildenhues <address@hidden> wrote:
> > | eval: 1: libtool_args+=: not found
> > | eval: 1: libtool_args+=: not found
[...]
> > In all likelihood, this is not a Libtool bug.
> 
> Yep, this specific problem is with librep-dev not setting CONFIG_SHELL
> explicitly, and I'll fix that in #570719.  But the bug I wanted to
> raise was that this general class of errors - running the libtool
> script with the wrong shell - does not cause a bad error code.

Good point.  Tagging this bug as upstream one.  Sorry for misreading
your bug report at first.

> If 'set -e' were added at the top of libtool, it would fail early.

Indeed.  However, libtool is currently not 'set -e' clean, in the sense
that several code pieces expect to continue if some unchecked code fails
(either they are meant to ignore failure, or $? is checked afterwards).
Examples include func_show_eval in general.m4sh, basically all code
pieces in ltmain.m4sh that reference $?, and probably some system-
specific code snippets in libtool.m4.

I'm sure improving things on this front would help as cleanup, but there
are several portability warts that other shells have with 'set -e' code
(esp. with loop constructs) that outright enabling it doesn't seem
helpful to me except for bug hunting.

> Feel free to 'wontfix' if that's not possible to do.

Well, it is certainly possible to guard against this specific bug, esp.
since it is still a fairly common one to happen, let's keep it open for
now.

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]