bug#47000: git libtool compiler flag handling busted on HP-UX

[Pavel Raiskup]

Hi Nick,

On Monday, March 8, 2021 5:13:23 AM CEST Nick Bowler wrote:
> 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

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

Libtool would inherit that change, once merged.

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.

Pavel

> 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
>
>