Bug#570723: rep-gtk and librep-dev bash/dash libtool breakage

2010-10-14 Thread Tim Retout 
 2010 09:11, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
 * Tim Retout wrote on Thu, Oct 14, 2010 at 09:36:07AM CEST:
 I almost just closed #570723 - but I'll reassign to libtool, because
 maybe it should 'set -e' or something (unless that's not portable).

 Issues such as this:

 | eval: 1: libtool_args+=: not found
 | eval: 1: libtool_args+=: not found

 typically come from configure running the tests under a different shell
 than libtool.  This is often because the configure.ac messes with $SHELL
 and/or $CONFIG_SHELL, or CONFIG_SHELL is set in the environment.

 The build log referenced looks like it ran under bash:

 | checking whether the shell understands some XSI constructs... yes
 | checking whether the shell understands +=... yes

 yet make uses /usr/lib/rep/x86_64-pc-kfreebsd-gnu/libtool which doesn't
 seem to have been created by configure.  I suspect that
 /usr/lib/rep/x86_64-pc-kfreebsd-gnu/libtool assumes /bin/sh is bash,
 because at the time and on the system it was created it was bash.

 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.  If
'set -e' were added at the top of libtool, it would fail early. Feel
free to 'wontfix' if that's not possible to do.

-- 
Tim Retout dioc...@debian.org



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570723: rep-gtk and librep-dev bash/dash libtool breakage

2010-10-14 Thread Ralf Wildenhues 
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 ralf.wildenh...@gmx.de 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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org