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

[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



_______________________________________________
Bug-libtool mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-libtool