GNU bug report logs - #30718
AIX: test failures (missing '[', shared lib problem)

Previous Next

To reply to this bug, email your comments to 30718 AT debbugs.gnu.org.

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

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

From: John Wiersba <jrw32982 <at> yahoo.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: coreutils-8.29 compilation failure using xlC on AIX
Date: Mon, 5 Mar 2018 20:48:46 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Build environment:
coreutils-8.29
AIX 6.1
xlC version:
    IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
    Version: 12.01.0000.0002
AIX make (/bin/make)


Environment variables:
export CC=xlC
export CFLAGS=-q64
export CXX=$CC
export CXXFLAGS=$CFLAGS
export LD=ld
export AR="ar -X64"
export LDFLAGS="-Wl,-bmaxdata:0x80000000"

Bug:
./configure succeeds
make fails:
    CC       src/stat.o
    "src/stat.c", line 598.19: 1506-045 (S) Undeclared identifier intmax_bufsize.
    "src/stat.c", line 598.19: 1506-1324 (S) Array size must have integer type.
Problematic code in src/stat.c:
    enum { intmax_bufsize = INT_BUFSIZE_BOUND (intmax_t) };
    static char str[intmax_bufsize ...


Description:
I see this enum technique used in slightly different ways in other parts of the source.  

I'm not sure of the rationale for using enum here, but apparently the AIX xlC compiler
doesn't like it.  Since it is the only use of this variable (intmax_bufsize) in this 

file, it is easy to replace the use of intmax_bufsize with its value INT_BUFSIZE_BOUND(intmax_t),
which allows the compilation to finish correctly.  I'm not aware of any other 

workaround for this issue.  Maybe it's a compiler bug?  But in any case, it would be 

nice if a source change didn't have to be made.

As an additional comment, it took me quite a while to find working values for
CFLAGS, AR, and LDFLAGS.  I'm not sure how you might accomplish it, but it would be
friendlier if, once it's determined that gcc is not available and xlC is available,
a reasonable set of default options were supplied, so that every user of xlC doesn't
have to rediscover some set defaults which allow the build to succeed.

Finally, I'm attaching the test-suite.log indicating a couple of failures and a few errors.

[test-suite.log (application/octet-stream, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Wiersba <jrw32982 <at> yahoo.com>, 30718 <at> debbugs.gnu.org
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Mon, 5 Mar 2018 15:55:51 -0800

[Message part 1 (text/plain, inline)]

On 03/05/2018 12:48 PM, John Wiersba wrote:
> I'm not sure of the rationale for using enum here, but apparently the AIX xlC compiler
> doesn't like it.

That's a bug in the IBM xlC compiler; could you please report it to IBM?

The code uses an enum because it wants to name the expression. The C 
standard requires that static array sizes have constant bounds, and 
enums are constants, so this technique conforms to C89 (as well as to 
C99 and C11). If the IBM compiler is complaining about it then it's not 
conforming to the standard. Most likely the compiler is incorrectly 
hoisting the static decl to be as if it were outside the function body, 
which is an incorrect transformation.

Anyway, I installed the attached patch into coreutils, to work around 
the compiler bug. Thanks for reporting the problem.

[0001-stat-work-around-IBM-xlC-bug.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Wiersba <jrw32982 <at> yahoo.com>, 30718-done <at> debbugs.gnu.org
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Mon, 5 Mar 2018 15:57:34 -0800

... and I'm marking the bug as done.

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

From: John Wiersba <jrw32982 <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 
 "30718-done <at> debbugs.gnu.org" <30718-done <at> debbugs.gnu.org>
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Tue, 6 Mar 2018 00:01:52 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Thanks, Paul.  Any comment on the other two parts of my bug report?

As an additional comment, it took me quite a while to find working values forCFLAGS, AR, and LDFLAGS.  I'm not sure how you might accomplish it, but it would be
friendlier if, once it's determined that gcc is not available and xlC is available,
a reasonable set of default options were supplied, so that every user of xlC doesn't
have to rediscover some set defaults which allow the build to succeed.

Finally, I'm attaching the test-suite.log indicating a couple of failures and a few errors.
-- John

      From: Paul Eggert <eggert <at> cs.ucla.edu>
 To: John Wiersba <jrw32982 <at> yahoo.com>; 30718-done <at> debbugs.gnu.org 
 Sent: Monday, March 5, 2018 6:57 PM
 Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
   
... and I'm marking the bug as done.


   

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Wiersba <jrw32982 <at> yahoo.com>,
 "30718-done <at> debbugs.gnu.org" <30718-done <at> debbugs.gnu.org>
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Mon, 5 Mar 2018 17:21:12 -0800

On 03/05/2018 04:01 PM, John Wiersba wrote:
> As an additional comment, it took me quite a while to find working 
> values for
> CFLAGS, AR, and LDFLAGS.  I'm not sure how you might accomplish it, 
> but it would be
> friendlier if, once it's determined that gcc is not available and xlC 
> is available,
> a reasonable set of default options were supplied, so that every user 
> of xlC doesn't
> have to rediscover some set defaults which allow the build to succeed.
>
> Finally, I'm attaching the test-suite.log indicating a couple of 
> failures and a few errors.

No, sorry, I missed both of those. I'll reopen the bug report. These all 
sound like they're lower priority, though.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 30718 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, jrw32982 <at> yahoo.com
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Mon, 5 Mar 2018 21:18:39 -0700

On 2018-03-05 06:21 PM, Paul Eggert wrote:
> On 03/05/2018 04:01 PM, John Wiersba wrote:
>> As an additional comment, it took me quite a while to find working 
>> values for
>> CFLAGS, AR, and LDFLAGS.  I'm not sure how you might accomplish it, 
>> but it would be
>> friendlier if, once it's determined that gcc is not available and xlC 
>> is available,
>> a reasonable set of default options were supplied, so that every user 
>> of xlC doesn't
>> have to rediscover some set defaults which allow the build to succeed.

Just recently we've added information about GCC's CFLAGS/LDFLAGS/AR
on AIX in the README:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f4fec336

Perhaps it's worth expanding and mentioning XLC flags ?
(as an interim fix until proper detection is made)

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

From: John Wiersba <jrw32982 <at> yahoo.com>
To: Assaf Gordon <assafgordon <at> gmail.com>, 
 "30718 <at> debbugs.gnu.org" <30718 <at> debbugs.gnu.org>, 
 "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Tue, 6 Mar 2018 13:23:29 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Hi, Assaf - 
I saw those newly added lines in the version of coreutils that I was compiling, and that was part of the information which led me to the set of environment variables I'm currently using.I think many people compiling on AIX will use XLC instead of GCC, since that's the "native" compiler.  It would be great to auto detect XLC and have some useful default flags for it.In lieu of that, it would be great to document a useful environment on AIX for those who use XLC.  I'm certainly happy to defer to other, more expert, AIX users about the values of those suggested environment variables, since I only do this kind of thing every N years when I get really fed up with AIX's pathetic set of native tools.
-- John

      From: Assaf Gordon <assafgordon <at> gmail.com>
 To: 30718 <at> debbugs.gnu.org; eggert <at> cs.ucla.edu; jrw32982 <at> yahoo.com 
 Sent: Monday, March 5, 2018 11:18 PM
 Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
   
On 2018-03-05 06:21 PM, Paul Eggert wrote:
> On 03/05/2018 04:01 PM, John Wiersba wrote:
>> As an additional comment, it took me quite a while to find working 
>> values for
>> CFLAGS, AR, and LDFLAGS.  I'm not sure how you might accomplish it, 
>> but it would be
>> friendlier if, once it's determined that gcc is not available and xlC 
>> is available,
>> a reasonable set of default options were supplied, so that every user 
>> of xlC doesn't
>> have to rediscover some set defaults which allow the build to succeed.

Just recently we've added information about GCC's CFLAGS/LDFLAGS/AR
on AIX in the README:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f4fec336

Perhaps it's worth expanding and mentioning XLC flags ?
(as an interim fix until proper detection is made)






   

[Message part 2 (text/html, inline)]

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: John Wiersba <jrw32982 <at> yahoo.com>, 30718 <at> debbugs.gnu.org
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Tue, 6 Mar 2018 22:00:33 +0100

On 03/05/2018 09:48 PM, John Wiersba wrote:
> Build environment:
> coreutils-8.29
> AIX 6.1

> Finally, I'm attaching the test-suite.log indicating a couple of failures and a few errors.

> FAIL: tests/misc/help-version
> =============================
>
> env: '[': No such file or directory
> env: '[': No such file or directory
> env: '[': No such file or directory
> FAIL: [
> 0+1 records in
> 0+1 records out
> FAIL tests/misc/help-version.sh (exit status: 1)

Somehow, the used 'env' does not seem to find '[' in PATH.
This is odd, as the test setup should care for this.
Would you please send the full "tests/misc/help-version.log"?

BTW: As there are only 3 instead of 5 ENOENTs for '[', I guess
that AIX doesn't have /dev/full, right?

> ERROR: tests/rm/rm-readdir-fail
> ===============================
>
> xlC: 1501-289 (W) Option -Wall was incorrectly specified. The option will be ignored.
> xlC: 1501-216 (W) command option --std=gnu99 is not recognized - passed to ld
> xlC: 1501-289 (W) Option -Wall was incorrectly specified. The option will be ignored.
> xlC: 1501-216 (W) command option --std=gnu99 is not recognized - passed to ld
> "k.c", line 17.41: 1506-068 (W) Operation between types "struct dirent*(*)(struct _dirdesc*)" and "void*" is not allowed.
> ld: 0706-012 The -h flag is not recognized.
> ld: 0706-012 The -a flag is not recognized.
> ld: 0706-012 The -- flag is not recognized.
> ld: 0706-012 The -t flag is not recognized.
> ld: 0706-027 The -d flag is ignored.
> ld: 0706-012 The -= flag is not recognized.
> ld: 0706-012 The -g flag is not recognized.
> ld: 0706-027 The -n flag is ignored.
> ld: 0706-005 Cannot find or open file: PIC
> 	ld:fopen(): No such file or directory
> rm-readdir-fail.sh: set-up failure: failed to build shared library
> ERROR tests/rm/rm-readdir-fail.sh (exit status: 99)

gcc_shared_ k.c k.so \
  || framework_failure_ 'failed to build shared library'
_____^^^^^^^^^^^^^^^^^^

We probably better should 'skip_' instead.

Thanks & have a nice day,
Berny

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

From: John Wiersba <jrw32982 <at> yahoo.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>, 
 "30718 <at> debbugs.gnu.org" <30718 <at> debbugs.gnu.org>
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
Date: Mon, 12 Mar 2018 13:37:29 +0000 (UTC)

[Message part 1 (text/plain, inline)]

There is no '[' in $PATH.  There is no /dev/full.

$ cat tests/misc/help-version.log
env: '[': No such file or directory
env: '[': No such file or directory
env: '[': No such file or directory
FAIL: [
0+1 records in
0+1 records out
FAIL tests/misc/help-version.sh (exit status: 1)


tests/test-suite.log attached

---


export CC=xlC
export CFLAGS=-q64

export CXX=$CC
export CXXFLAGS=$CFLAGS

export LD=ld
export AR="ar -X64"

export LDFLAGS="-Wl,-bmaxdata:0x80000000"


patched src/stat.c to allow it to compile (xlC compiler issue with intmax_bufsize, reported earlier)

./configure --disable-threads && make && make check





________________________________
From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: John Wiersba <jrw32982 <at> yahoo.com>; 30718 <at> debbugs.gnu.org 
Sent: Tuesday, March 6, 2018 4:00 PM
Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX



On 03/05/2018 09:48 PM, John Wiersba wrote:

> Build environment:
> coreutils-8.29
> AIX 6.1

> Finally, I'm attaching the test-suite.log indicating a couple of failures and a few errors.

> FAIL: tests/misc/help-version
> =============================
>
> env: '[': No such file or directory
> env: '[': No such file or directory
> env: '[': No such file or directory
> FAIL: [
> 0+1 records in
> 0+1 records out
> FAIL tests/misc/help-version.sh (exit status: 1)

Somehow, the used 'env' does not seem to find '[' in PATH.
This is odd, as the test setup should care for this.
Would you please send the full "tests/misc/help-version.log"?

BTW: As there are only 3 instead of 5 ENOENTs for '[', I guess
that AIX doesn't have /dev/full, right?

> ERROR: tests/rm/rm-readdir-fail
> ===============================
>
> xlC: 1501-289 (W) Option -Wall was incorrectly specified. The option will be ignored.
> xlC: 1501-216 (W) command option --std=gnu99 is not recognized - passed to ld
> xlC: 1501-289 (W) Option -Wall was incorrectly specified. The option will be ignored.
> xlC: 1501-216 (W) command option --std=gnu99 is not recognized - passed to ld
> "k.c", line 17.41: 1506-068 (W) Operation between types "struct dirent*(*)(struct _dirdesc*)" and "void*" is not allowed.
> ld: 0706-012 The -h flag is not recognized.
> ld: 0706-012 The -a flag is not recognized.
> ld: 0706-012 The -- flag is not recognized.
> ld: 0706-012 The -t flag is not recognized.
> ld: 0706-027 The -d flag is ignored.
> ld: 0706-012 The -= flag is not recognized.
> ld: 0706-012 The -g flag is not recognized.
> ld: 0706-027 The -n flag is ignored.
> ld: 0706-005 Cannot find or open file: PIC
>     ld:fopen(): No such file or directory
> rm-readdir-fail.sh: set-up failure: failed to build shared library
> ERROR tests/rm/rm-readdir-fail.sh (exit status: 99)

gcc_shared_ k.c k.so \
  || framework_failure_ 'failed to build shared library'
_____^^^^^^^^^^^^^^^^^^

We probably better should 'skip_' instead.

Thanks & have a nice day,
Berny

[test-suite.log (application/octet-stream, attachment)]

Previous Next

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