GNU bug report logs -
#30718
AIX: test failures (missing '[', shared lib problem)
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 5 Mar 2018 17:21:12 -0800
with message-id <f1195cf8-c772-d15f-1567-ea87b77e2ab0 <at> cs.ucla.edu>
and subject line Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX
has caused the debbugs.gnu.org bug report #30718,
regarding coreutils-8.29 compilation failure using xlC on AIX
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
30718: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30718
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (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 part 5 (message/rfc822, inline)]
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.
This bug report was last modified 6 years and 233 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.