Re: libtool-2.2.10: print vs. printf
[ dropping libtool@ ]
Hi Markus,
* Markus Duft wrote on Thu, Oct 28, 2010 at 10:42:46AM CEST:
On 10/27/2010 08:13 PM, Ralf Wildenhues wrote:
oh, well - good to know that ;) is there some documentation i can
refer to wrt to this requirement? it seems we need to adapt some
things, as this was not the case with previous versions - and i
need to argue the need to do the work ;)
Good point actually. We don't currently have such documentation.
The Autoconf manual has some bits on $CONFIG_SHELL, but nothing
about the libtool script of course.
OK to fix that with the patch below, and add Markus to THANKS?
i'd additionally mention, that a shell mismatch can make libtool fail,
because of the print/printf mismatch. this is (AFAICT) the only thing
that really _breaks_ when the configure shell was a ksh, and the make
shell is a bash (at least for me).
No, that is not the only thing that breaks. Actually, for example on
Solaris, *lots* of other things will break as well. And we don't really
guarantee what breaks on what system and with which combination of
shells. So let me make the statement a wee bit stronger by squashing in
this diff. Hope that is enough.
I've pushed the combined patch now, since there were no more comments.
Thanks,
Ralf
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1330,7 +1330,8 @@ The current @command{libtool} implementation is done with
a shell script
that needs to be invoked by the shell which @command{configure} chose for
configuring @command{libtool} (@pxref{config.status Invocation, , The
Autoconf Manual, autoconf, The Autoconf Manual}). This shell is set in
-the she-bang (@samp{#!}) line of the @command{libtool} script.
+the she-bang (@samp{#!}) line of the @command{libtool} script. Using a
+different shell may cause undefined behavior.
The @var{mode-args} are a variable number of arguments, depending on the
selected operation mode. In general, each @var{mode-arg} is interpreted
Re: libtool-2.2.10: print vs. printf
On 10/27/2010 08:13 PM, Ralf Wildenhues wrote:
[snip]
oh, well - good to know that ;) is there some documentation i can refer to
wrt to this requirement? it seems we need to adapt some things, as this was
not the case with previous versions - and i need to argue the need to do the
work ;)
Good point actually. We don't currently have such documentation. The
Autoconf manual has some bits on $CONFIG_SHELL, but nothing about the
libtool script of course.
OK to fix that with the patch below, and add Markus to THANKS?
i'd additionally mention, that a shell mismatch can make libtool fail, because
of the print/printf mismatch. this is (AFAICT) the only thing that really
_breaks_ when the configure shell was a ksh, and the make shell is a bash (at
least for me).
otherwise, thanks for the docs ;)
markus
Thanks,
Ralf
docs: mention shell requirement for libtool script.
* doc/libtool.texi (Invoking libtool): Document that the shell
used to invoke libtool needs to be the same used to configure
it.
* THANKS: Update.
Report by Markus Duft.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 076b67b..c84b92a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1326,6 +1326,12 @@ can be achieved using either option @option{-v} or
option
Print libtool version information and exit.
@end table
+The current @command{libtool} implementation is done with a shell script
+that needs to be invoked by the shell which @command{configure} chose for
+configuring @command{libtool} (@pxref{config.status Invocation, , The
+Autoconf Manual, autoconf, The Autoconf Manual}). This shell is set in
+the she-bang (@samp{#!}) line of the @command{libtool} script.
+
The @var{mode-args} are a variable number of arguments, depending on the
selected operation mode. In general, each @var{mode-arg} is interpreted
by programs libtool invokes, rather than libtool itself.
Re: libtool-2.2.10: print vs. printf
Hi Markus.
* Markus Duft wrote on Wed, Oct 27, 2010 at 09:13:17AM CEST:
On 10/23/2010 09:16 AM, Ralf Wildenhues wrote:
* Markus Duft wrote on Fri, Oct 22, 2010 at 09:59:27AM CEST:
or am i wrong, and it is specified, that the shells that configure and
make use have to be the same?
Exactly. The bug is that the shell used during configure, and the shell
invoking libtool, are not the same. This bug can be caused by different
things, either you setting SHELL in Makefile.in, or SHELL or
CONFIG_SHELL in configure.ac, or something similar. We cannot tell
without more details.
oh, well - good to know that ;) is there some documentation i can refer to
wrt to this requirement? it seems we need to adapt some things, as this was
not the case with previous versions - and i need to argue the need to do the
work ;)
Good point actually. We don't currently have such documentation. The
Autoconf manual has some bits on $CONFIG_SHELL, but nothing about the
libtool script of course.
OK to fix that with the patch below, and add Markus to THANKS?
Thanks,
Ralf
docs: mention shell requirement for libtool script.
* doc/libtool.texi (Invoking libtool): Document that the shell
used to invoke libtool needs to be the same used to configure
it.
* THANKS: Update.
Report by Markus Duft.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 076b67b..c84b92a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1326,6 +1326,12 @@ can be achieved using either option @option{-v} or option
Print libtool version information and exit.
@end table
+The current @command{libtool} implementation is done with a shell script
+that needs to be invoked by the shell which @command{configure} chose for
+configuring @command{libtool} (@pxref{config.status Invocation, , The
+Autoconf Manual, autoconf, The Autoconf Manual}). This shell is set in
+the she-bang (@samp{#!}) line of the @command{libtool} script.
+
The @var{mode-args} are a variable number of arguments, depending on the
selected operation mode. In general, each @var{mode-arg} is interpreted
by programs libtool invokes, rather than libtool itself.
