emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#30718: closed (coreutils-8.29 compilation failure


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#30718: closed (coreutils-8.29 compilation failure using xlC on AIX)
Date: Mon, 05 Mar 2018 23:58:02 +0000

Your message dated Mon, 5 Mar 2018 15:57:34 -0800
with message-id <address@hidden>
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
address@hidden)


-- 
30718: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30718
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: coreutils-8.29 compilation failure using xlC on AIX Date: Mon, 5 Mar 2018 20:48:46 +0000 (UTC)
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.

Attachment: test-suite.log
Description: Binary data


--- End Message ---
--- Begin Message --- Subject: Re: bug#30718: coreutils-8.29 compilation failure using xlC on AIX Date: Mon, 5 Mar 2018 15:57:34 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
... and I'm marking the bug as done.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]