GNU bug report logs -
#47000
git libtool compiler flag handling busted on HP-UX
Previous Next
Reported by: Nick Bowler <nbowler <at> draconx.ca>
Date: Mon, 8 Mar 2021 04:16:01 UTC
Severity: normal
Fixed in version 2.4.6.47-fc77
Done: Pavel Raiskup <praiskup <at> redhat.com>
Bug is archived. No further changes may be made.
Full log
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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
>
>
This bug report was last modified 3 years and 242 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.