GNU bug report logs - #47000
git libtool compiler flag handling busted on HP-UX

Previous Next

Package: libtool;

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

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org, Nick Bowler <nbowler <at> draconx.ca>
Subject: Re: git libtool compiler flag handling busted on HP-UX
Date: Mon, 25 Oct 2021 00:27:05 +0200
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.