--- Begin Message ---
|
Subject: |
git libtool compiler flag handling busted on HP-UX |
|
Date: |
Sun, 7 Mar 2021 23:15:10 -0500 |
[resending to correct address]
Hi,
I've been doing some portability testing recently and I've noticed what
appears to be an issue in the current libtool development sources...
On HP-UX 11.11, with libtool 2.4.6, things seem to work OK:
% cat >test.c <<'EOF'
#include <stdio.h>
int main(void)
{
printf("%s\n", TESTMACRO);
return 0;
}
EOF
% libtool --version
libtool (GNU libtool) 2.4.6
[...]
% libtool --tag=CC --mode=compile cc -c -DTESTMACRO=\"test\" test.c
libtool: compile: cc -c -DTESTMACRO=\"test\" test.c +Z -DPIC -o .libs/test.o
libtool: compile: cc -c -DTESTMACRO=\"test\" test.c -o test.o >/dev/null 2>&1
However, with git master, the -DTESTMACRO=\"test\" option seems to get
messed up:
% libtool --version
libtool (GNU libtool) 2.4.6.44-b9b4
[...]
% libtool --tag=CC --mode=compile cc -c -DTESTMACRO=\"test\" test.c
libtool: compile: cc -c "" test.c +Z -DPIC -o .libs/test.o
cc: "test.c", line 3: error 1588: "TESTMACRO" undefined.
Most options seem to work OK, but as soon as the double quotes appear
in the macro definition then I see this problem.
I have tested and found that the first commit to exhibit this behaviour is:
32f0df9835ac ("libtool: mitigate the $set_quote_subst slowdown")
On investigation, it appears this problem occurs because the func_quote
function in libtool attempts to split on backslashes by setting IFS='\'
but this procedure appears ineffective on the HP-UX shell. For example:
% IFS='\'
% hello='foo\bar\baz'
% printf '%s\n' "$hello" $hello
foo\bar\baz
foo\bar\baz
This behaviour causes the state machine to just throw away all the
input on the very first transition out of the start state, so I think
these shell loops will simply never work in this environment.
Looking into this further, the HP-UX shell derives from ksh88 and this
does not appear to be the only ksh88 derivative with this problem. For
example, I tested libtool using heirloom-sh on a GNU/Linux system and I
observe identical behaviour. So I think it's fair to say that setting
IFS='\' is not portable.
As an aside, Gentoo has backported this patch into their libtool-2.4.6
package, which means that if you prepare a release bundle on Gentoo you
will get this failure in your own packages, even though upstream
libtool-2.4.6 would work just fine. Oops...
Cheers,
Nick
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#47000: git libtool compiler flag handling busted on HP-UX |
|
Date: |
Tue, 16 Nov 2021 14:24:39 +0100 |
Version: 2.4.6.47-fc77
On Monday, October 25, 2021 10:45:05 PM CET Nick Bowler wrote:
> Hi Pavel,
>
> On 2021-10-24, Pavel Raiskup <praiskup@redhat.com> wrote:
> > On Monday, March 8, 2021 5:13:23 AM CEST Nick Bowler wrote:
> >> On HP-UX 11.11, with libtool 2.4.6,
> [...]
> >> On investigation, it appears this problem occurs because the func_quote
> >> function in libtool attempts to split on backslashes by setting IFS='\'
> >> but this procedure appears ineffective on the HP-UX shell. For example:
> >>
> >> % IFS='\'
> >> % hello='foo\bar\baz'
> >> % printf '%s\n' "$hello" $hello
> >> foo\bar\baz
> >> foo\bar\baz
> >
> > Thank you for the report! And sorry for the delay.
> >
> > Would you mind testing 'make check' from this PR on the affected system?
> >
> > https://github.com/gnulib-modules/bootstrap/pull/25
>
> As the Makefile uses the GNU-specific $(shell ...) construction,
> "make check" does not work out of the box on HP-UX. I worked around
> the problem by running
>
> % make abs_aux_dir=$PWD/build-aux abs_srcdir=$PWD/tests check
>
> > I hope I fixed there the problem with IFS='\' (even though it is just a poor
> > fallback to the slower SED variant, anyone is welcome to provide better
> > solution).
> >
> > Perhaps there are other problems so it would be nice to see the testsuite
> > results.
>
> The output (attached, gzipped) is not entirely obvious to me but I
> assume this means everything passed? As a point of comparison, without
> your changes there are many errors reported.
>
> For the record, the empty field bug described in the change log (which
> is observed with heirloom-sh and presumably also Solaris 10 /bin/sh)
> regarding empty fields does not appear to be a problem on HP-UX 11:
I tried to update the commit message(s) a but. And I believe this is fixed now
(merged to libtool):
https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=fc7779d7d8edfec83ce74c39f197ae2f1225873a
Thank you for testing!
Pavel
> % var='a::b'; IFS=':'; set dummy $var
> % printf '%s\n' "$#" "$2" "$3" "$4"
> 4
> a
>
> b
>
> Thanks,
> Nick
--- End Message ---