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.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47000 in the body.
You can then email your comments to 47000 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#47000; Package libtool. (Mon, 08 Mar 2021 04:16:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nick Bowler <nbowler <at> draconx.ca>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Mon, 08 Mar 2021 04:16:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: bug-libtool <at> gnu.org
Cc: Pavel Raiskup <praiskup <at> redhat.com>
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




Information forwarded to bug-libtool <at> gnu.org:
bug#47000; Package libtool. (Sun, 24 Oct 2021 22:28:02 GMT) Full text and rfc822 format available.

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








Information forwarded to bug-libtool <at> gnu.org:
bug#47000; Package libtool. (Mon, 25 Oct 2021 20:46:01 GMT) Full text and rfc822 format available.

Message #11 received at 47000 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Pavel Raiskup <praiskup <at> redhat.com>
Cc: 47000 <at> debbugs.gnu.org
Subject: Re: bug#47000: git libtool compiler flag handling busted on HP-UX
Date: Mon, 25 Oct 2021 16:45:05 -0400
[Message part 1 (text/plain, inline)]
Hi Pavel,

On 2021-10-24, Pavel Raiskup <praiskup <at> 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:

  % var='a::b'; IFS=':'; set dummy $var
  % printf '%s\n' "$#" "$2" "$3" "$4"
  4
  a

  b

Thanks,
  Nick
[test.log.gz (application/x-gzip, attachment)]

Reply sent to Pavel Raiskup <praiskup <at> redhat.com>:
You have taken responsibility. (Tue, 16 Nov 2021 13:25:03 GMT) Full text and rfc822 format available.

Notification sent to Nick Bowler <nbowler <at> draconx.ca>:
bug acknowledged by developer. (Tue, 16 Nov 2021 13:25:03 GMT) Full text and rfc822 format available.

Message #16 received at 47000-done <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 47000-done <at> debbugs.gnu.org
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 <at> 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








bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 15 Dec 2021 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 94 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.