GNU bug report logs - #17773
AIX build errors with coreutils-8.22

Previous Next

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

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 15:38:09 +0200

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

For the most part, the configure and build runs quite clean. There are few
warnings about assignment of a char* to a const char*.

A few utils are missing the -lpthread library assignment:

To fix this, using make -i I indentified the group (after it was more than
1)

These four - at least -

cc   -O2 -qlanglvl=extc99   -o src/csplit src/csplit.o src/libver.a
lib/libcoreutils.a  lib/libcoreutils.a -lpthread
cc   -O2 -qlanglvl=extc99   -o src/expr src/expr.o src/libver.a
lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
cc   -O2 -qlanglvl=extc99   -o src/nl src/nl.o src/libver.a
lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
cc   -O2 -qlanglvl=extc99   -o src/tac src/tac.o src/libver.a
lib/libcoreutils.a  lib/libcoreutils.a  -lpthread

Further there are two source files that are not compiling because of undefs

make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
  CC       src/od.o
"src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
_GL_FLT_PREC_BOUND.
"src/od.c", line 432.47: 1506-1324 (S) Array size must have integer type.
"src/od.c", line 433.49: 1506-045 (S) Undeclared identifier
_GL_DBL_PREC_BOUND.
"src/od.c", line 433.49: 1506-1324 (S) Array size must have integer type.
"src/od.c", line 434.60: 1506-045 (S) Undeclared identifier
_GL_LDBL_PREC_BOUND.
"src/od.c", line 434.60: 1506-1324 (S) Array size must have integer type.
make[2]: [src/od.o] Error 1 (ignored)
  CCLD     src/od
cc: 1501-228 (W) input file src/od.o not found
make[2]: [src/od] Error 252 (ignored)
  CCLD     src/ptx
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
make[2]: [src/ptx] Error 8 (ignored)
  CC       src/getlimits.o
"src/getlimits.c", line 110.45: 1506-045 (S) Undeclared identifier
_GL_FLT_PREC_BOUND.
"src/getlimits.c", line 110.45: 1506-1324 (S) Array size must have integer
type.
"src/getlimits.c", line 111.46: 1506-045 (S) Undeclared identifier
_GL_DBL_PREC_BOUND.
"src/getlimits.c", line 111.46: 1506-1324 (S) Array size must have integer
type.
"src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
_GL_LDBL_PREC_BOUND.
"src/getlimits.c", line 112.53: 1506-1324 (S) Array size must have integer
type.
make[2]: [src/getlimits.o] Error 1 (ignored)
  CCLD     src/getlimits
cc: 1501-228 (W) input file src/getlimits.o not found

Not sure how to resolve the missing definitions - do not wish to make
assumptions.

Regards,
Michael Felt

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Re: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 15:40:40 +0200

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

Just noticed: need to add:
cc   -O2 -qlanglvl=extc99   -o src/ptx src/ptx.o src/libver.a
lib/libcoreutils.a  lib/libcoreutils.a  -lpthread


On Fri, Jun 13, 2014 at 3:38 PM, Michael Felt <mamfelt <at> gmail.com> wrote:

> For the most part, the configure and build runs quite clean. There are few
> warnings about assignment of a char* to a const char*.
>
> A few utils are missing the -lpthread library assignment:
>
> To fix this, using make -i I indentified the group (after it was more than
> 1)
>
> These four - at least -
>
> cc   -O2 -qlanglvl=extc99   -o src/csplit src/csplit.o src/libver.a
> lib/libcoreutils.a  lib/libcoreutils.a -lpthread
> cc   -O2 -qlanglvl=extc99   -o src/expr src/expr.o src/libver.a
> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
> cc   -O2 -qlanglvl=extc99   -o src/nl src/nl.o src/libver.a
> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
> cc   -O2 -qlanglvl=extc99   -o src/tac src/tac.o src/libver.a
> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
>
> Further there are two source files that are not compiling because of undefs
>
> make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
>   CC       src/od.o
> "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
> _GL_FLT_PREC_BOUND.
> "src/od.c", line 432.47: 1506-1324 (S) Array size must have integer type.
> "src/od.c", line 433.49: 1506-045 (S) Undeclared identifier
> _GL_DBL_PREC_BOUND.
> "src/od.c", line 433.49: 1506-1324 (S) Array size must have integer type.
> "src/od.c", line 434.60: 1506-045 (S) Undeclared identifier
> _GL_LDBL_PREC_BOUND.
> "src/od.c", line 434.60: 1506-1324 (S) Array size must have integer type.
> make[2]: [src/od.o] Error 1 (ignored)
>   CCLD     src/od
> cc: 1501-228 (W) input file src/od.o not found
> make[2]: [src/od] Error 252 (ignored)
>   CCLD     src/ptx
> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock
> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock
> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init
> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.
> make[2]: [src/ptx] Error 8 (ignored)
>   CC       src/getlimits.o
> "src/getlimits.c", line 110.45: 1506-045 (S) Undeclared identifier
> _GL_FLT_PREC_BOUND.
> "src/getlimits.c", line 110.45: 1506-1324 (S) Array size must have integer
> type.
> "src/getlimits.c", line 111.46: 1506-045 (S) Undeclared identifier
> _GL_DBL_PREC_BOUND.
> "src/getlimits.c", line 111.46: 1506-1324 (S) Array size must have integer
> type.
> "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
> _GL_LDBL_PREC_BOUND.
> "src/getlimits.c", line 112.53: 1506-1324 (S) Array size must have integer
> type.
> make[2]: [src/getlimits.o] Error 1 (ignored)
>   CCLD     src/getlimits
> cc: 1501-228 (W) input file src/getlimits.o not found
>
> Not sure how to resolve the missing definitions - do not wish to make
> assumptions.
>
> Regards,
> Michael Felt
>

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Re: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 15:59:23 +0200

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

p.s. for comparison - went back in time a bit and tried version 8-20. Here
a summary of how that progressed (note, the warnings here are comparable to
the warnings in 8.22)

FORCE_UNSAFE_CONFIGURE=1 buildaix -d
+ CPPFLAGS="-I/opt/include" CFLAGS="-O2 -qlanglvl=extc99" ./configure \
        --prefix=/opt/coreutils \
        --sysconfdir=/var/coreutils/etc \
        --sharedstatedir=/var/coreutils/com \
        --localstatedir=/var/coreutils \
        --mandir=/usr/share/man \
        --infodir=/opt/share/info/coreutils  \
                > build/aix/configure.out
cmp: EOF on conftest.ok
configure: WARNING: libattr development library was not found or not usable.
configure: WARNING: GNU coreutils will be built without xattr support.
configure: WARNING: libcap library was not found or not usable.
configure: WARNING: GNU coreutils will be built without capability support.
configure: WARNING: libgmp development library was not found or not usable.
configure: WARNING: GNU coreutils will be built without GMP support.
+ /opt/bin/make > build/aix/make.out
"lib/set-mode-acl.c", line 630.18: 1506-280 (W) Function argument
assignment between types "char*" and "const char*" is not allowed.
"lib/copy-acl.c", line 510.19: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
"lib/copy-acl.c", line 516.19: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
"lib/file-has-acl.c", line 875.20: 1506-280 (W) Function argument
assignment between types "char*" and "const char*" is not allowed.
"lib/euidaccess.c", line 84.19: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
"lib/mountlist.c", line 829.45: 1506-280 (W) Function argument assignment
between types "char*" and "struct vmount*" is not allowed.
"lib/mountlist.c", line 834.46: 1506-280 (W) Function argument assignment
between types "char*" and "struct vmount*" is not allowed.
"lib/readutmp.c", line 100.23: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
    1500-030: (I) INFORMATION: copy_internal: Additional optimization may
be attained by recompiling and specifying MAXMEM option with a value
greater than 8192.
    1500-030: (I) INFORMATION: copy_internal: Additional optimization may
be attained by recompiling and specifying MAXMEM option with a value
greater than 8192.
"src/stat.c", line 1204.25: 1506-280 (W) Function argument assignment
between types "struct statvfs64* restrict" and "struct statvfs*" is not
allowed.
      77  1500-010: (W) WARNING in main: Infinite loop.  Program may not
stop.
+ /opt/bin/make install DESTDIR=/var/tmp/root/coreutils-8.20.0.0 >
build/aix/install.out
/opt/bin/install: cannot create regular file
`/var/tmp/root/coreutils-8.20.0.0/opt/coreutils/lib/lib/charset.alias': No
such file or directory
+ mkinstallp.ksh /var/tmp/root/coreutils-8.20.0.0 > build/aix/mkinstallp.out
==============================
aixtools.coreutils:aixtools.coreutils.man:8.20.0.0::I:T:::::N:man pages
2014.Jun.13 13.56 CUT::::0::
aixtools.coreutils:aixtools.coreutils.rte:8.20.0.0::I:T:::::N:coreutils
2014.Jun.13 13.56 CUT::::0::
aixtools.coreutils:aixtools.coreutils.share:8.20.0.0::I:T:::::N:share and
documentation 2014.Jun.13 13.56 CUT::::0::
==============================
root <at> x093:[/data/prj/gnu/coreutils/coreutils-8.20]


On Fri, Jun 13, 2014 at 3:40 PM, Michael Felt <mamfelt <at> gmail.com> wrote:

> Just noticed: need to add:
> cc   -O2 -qlanglvl=extc99   -o src/ptx src/ptx.o src/libver.a
> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
>
>
> On Fri, Jun 13, 2014 at 3:38 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>
>> For the most part, the configure and build runs quite clean. There are
>> few warnings about assignment of a char* to a const char*.
>>
>> A few utils are missing the -lpthread library assignment:
>>
>> To fix this, using make -i I indentified the group (after it was more
>> than 1)
>>
>> These four - at least -
>>
>> cc   -O2 -qlanglvl=extc99   -o src/csplit src/csplit.o src/libver.a
>> lib/libcoreutils.a  lib/libcoreutils.a -lpthread
>> cc   -O2 -qlanglvl=extc99   -o src/expr src/expr.o src/libver.a
>> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
>> cc   -O2 -qlanglvl=extc99   -o src/nl src/nl.o src/libver.a
>> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
>> cc   -O2 -qlanglvl=extc99   -o src/tac src/tac.o src/libver.a
>> lib/libcoreutils.a  lib/libcoreutils.a  -lpthread
>>
>> Further there are two source files that are not compiling because of
>> undefs
>>
>> make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
>>   CC       src/od.o
>> "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
>> _GL_FLT_PREC_BOUND.
>> "src/od.c", line 432.47: 1506-1324 (S) Array size must have integer type.
>> "src/od.c", line 433.49: 1506-045 (S) Undeclared identifier
>> _GL_DBL_PREC_BOUND.
>> "src/od.c", line 433.49: 1506-1324 (S) Array size must have integer type.
>> "src/od.c", line 434.60: 1506-045 (S) Undeclared identifier
>> _GL_LDBL_PREC_BOUND.
>> "src/od.c", line 434.60: 1506-1324 (S) Array size must have integer type.
>> make[2]: [src/od.o] Error 1 (ignored)
>>   CCLD     src/od
>> cc: 1501-228 (W) input file src/od.o not found
>> make[2]: [src/od] Error 252 (ignored)
>>   CCLD     src/ptx
>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock
>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock
>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init
>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
>> information.
>> make[2]: [src/ptx] Error 8 (ignored)
>>   CC       src/getlimits.o
>> "src/getlimits.c", line 110.45: 1506-045 (S) Undeclared identifier
>> _GL_FLT_PREC_BOUND.
>> "src/getlimits.c", line 110.45: 1506-1324 (S) Array size must have
>> integer type.
>> "src/getlimits.c", line 111.46: 1506-045 (S) Undeclared identifier
>> _GL_DBL_PREC_BOUND.
>> "src/getlimits.c", line 111.46: 1506-1324 (S) Array size must have
>> integer type.
>> "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
>> _GL_LDBL_PREC_BOUND.
>> "src/getlimits.c", line 112.53: 1506-1324 (S) Array size must have
>> integer type.
>> make[2]: [src/getlimits.o] Error 1 (ignored)
>>   CCLD     src/getlimits
>> cc: 1501-228 (W) input file src/getlimits.o not found
>>
>> Not sure how to resolve the missing definitions - do not wish to make
>> assumptions.
>>
>> Regards,
>> Michael Felt
>>
>
>

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

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Michael Felt <mamfelt <at> gmail.com>
Cc: Paul Eggert <eggert <at> CS.UCLA.EDU>, 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 16:26:14 +0100

On 06/13/2014 02:38 PM, Michael Felt wrote:
> For the most part, the configure and build runs quite clean. There are few
> warnings about assignment of a char* to a const char*.
> 
> A few utils are missing the -lpthread library assignment:

So you needed to add -lpthread to csplit, expr, nl, tac and ptx.
The highest common factor there is use of the regex module.
Looking at that in gnulib I see this change:
  http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=55ba71f4
That change is fine I think and only means that threading
primitives will be used in the regex replacement _if_
your package is using threads, i.e. has referenced the threadlib gnulib module.
Now coreutils does not reference this module directly, only referencing
the separate and simpler pthread module.
However threadlib is referenced indirectly through the timer-time module.

A quick fix that might work for you, is to run configure with the --disable-threads option.
That shouldn't disable the multithreading in sort I think, but allow the build to proceed?

As for fixing this up, I might change the timer-time module to use the pthread module instead.
The timer-time issue was only noticed with glibc and hence pthreads anyway.

BTW Paul I see in the threadlib module, the addition of _REENTRANT
or _THREAD_SAFE defines on some platforms.
Should we be doing that also in the pthread module?

thanks,
Pádraig.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Michael Felt <mamfelt <at> gmail.com>
Cc: 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 16:37:05 +0100

On 06/13/2014 02:38 PM, Michael Felt wrote:

> make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
>   CC       src/od.o
> "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
> _GL_FLT_PREC_BOUND.

>   CC       src/getlimits.o

> "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
> _GL_LDBL_PREC_BOUND.


I think Paul has already avoided this AIX compiler bug,
and so this will be fixed in the upcoming coreutils-8.23
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6f053ff1

thanks,
Pádraig.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Michael Felt <mamfelt <at> gmail.com>
Cc: 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 08:48:01 -0700

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

Pádraig Brady wrote:

> threading primitives will be used in the regex replacement _if_
> your package is using threads, i.e. has referenced the threadlib gnulib module.

Unfortunately regex also uses threads if the pthread module is used, and 
that's the problem here.  Some coreutils commands ('sort') use threads 
and others don't, but the commands that use threads are careful to not 
invoke anything like stdio or regex in an area where it wouldn't be 
thread-safe.  So I installed the attached hack instead: it abuses 
unlocked-io to mean "unlocked everything" but seemed simpler than 
anything else I could think of.  It fixes the reported problem on AIX 
anyway.

> Paul I see in the threadlib module, the addition of _REENTRANT
> or _THREAD_SAFE defines on some platforms.
> Should we be doing that also in the pthread module?

We do have a problem here.  Won't defining _THREAD_SAFE run into 
problems when combined with unlocked-io on AIX?

To be honest, the unlocked-io stuff seems so quaint now.  How much does 
it really help performance?  Perhaps we should retire it, or turn it 
into a no-op?

[0001-regex-don-t-be-multithreaded-if-USE_UNLOCKED_IO.patch (text/plain, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Michael Felt <mamfelt <at> gmail.com>
Cc: 17773-done <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 08:57:52 -0700

Pádraig Brady wrote:
> I think Paul has already avoided this AIX compiler bug

Yes, and combined with the regex_internal.h fix this addresses all the 
points raised in this bug report so I'm closing it.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Michael Felt <mamfelt <at> gmail.com>, 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 18:29:16 +0100

On 06/13/2014 04:48 PM, Paul Eggert wrote:
> Pádraig Brady wrote:

>> Paul I see in the threadlib module, the addition of _REENTRANT
>> or _THREAD_SAFE defines on some platforms.
>> Should we be doing that also in the pthread module?
> 
> We do have a problem here.  Won't defining _THREAD_SAFE run into problems when combined with unlocked-io on AIX?
> 
> To be honest, the unlocked-io stuff seems so quaint now.  How much does it really help performance?  Perhaps we should retire it, or turn it into a no-op?

Well it had a large impact when I last checked (a long time ago now),
due to avoiding the function call per character as well as the locking.

The unlocked-io module does undermine any IO protections enabled with the
_REENTRANT or _THREAD_SAFE macros, but that's no different to what happens
now with threadlib, and is essentially the "unlocked-io trumps threads"
assumption you made in the last gnulib regex fix.

So I'd be inclined to add those definitions in the pthread module,
but if not we could define at the top of sort.c at least?
I'm remembering these macros also protecting access to errno
on Solaris, and I see that concurrent sets/gets of errno are
done in xstrxfrm() in sort.

cheers,
Pádraig.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Michael Felt <mamfelt <at> gmail.com>, 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Fri, 13 Jun 2014 10:57:48 -0700

On 06/13/2014 10:29 AM, Pádraig Brady wrote:
> So I'd be inclined to add those definitions in the pthread module,
> but if not we could define at the top of sort.c at least?

The latter doesn't sound safe, since it would mean the files in 
libcoreutils.a would be compiled without -D_THREAD_SAFE and would thus 
access a global shared errno even when linked with sort.c. So I vote for 
the former.

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

From: Michael Felt <mamfelt <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Sat, 14 Jun 2014 17:57:00 +0200

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

I am "packaging" on a "clean" system, i.e., as few dependancies as
possible. And I have some warnings about certain features not being
included because the libraries are missing.

Further, just compiling by manually adding -pthread seems to be working.
Once I have the defines needed for the other programs I will run "make
check"

Thanks for the quick replies (I was on a plane and could not reply back
earlier).


On Fri, Jun 13, 2014 at 7:57 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 06/13/2014 10:29 AM, Pádraig Brady wrote:
>
>> So I'd be inclined to add those definitions in the pthread module,
>> but if not we could define at the top of sort.c at least?
>>
>
> The latter doesn't sound safe, since it would mean the files in
> libcoreutils.a would be compiled without -D_THREAD_SAFE and would thus
> access a global shared errno even when linked with sort.c. So I vote for
> the former.
>
>

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Sat, 14 Jun 2014 18:00:14 +0200

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

Blind in one eye, could not see out the other: I thought I had listed the
warnings - they were above:
configure: WARNING: libattr development library was not found or not usable.
configure: WARNING: GNU coreutils will be built without xattr support.
configure: WARNING: libcap library was not found or not usable.
configure: WARNING: GNU coreutils will be built without capability support.
configure: WARNING: libgmp development library was not found or not usable.
configure: WARNING: GNU coreutils will be built without GMP support.

For the rest, I would rather not know the itty-gritty. My main reason for
coreutils is because of the differences between AIX install, bsd install
and coreutils install. coreutils version works where AIX and bsd fail.


On Sat, Jun 14, 2014 at 5:57 PM, Michael Felt <mamfelt <at> gmail.com> wrote:

> I am "packaging" on a "clean" system, i.e., as few dependancies as
> possible. And I have some warnings about certain features not being
> included because the libraries are missing.
>
> Further, just compiling by manually adding -pthread seems to be working.
> Once I have the defines needed for the other programs I will run "make
> check"
>
> Thanks for the quick replies (I was on a plane and could not reply back
> earlier).
>
>
> On Fri, Jun 13, 2014 at 7:57 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
>> On 06/13/2014 10:29 AM, Pádraig Brady wrote:
>>
>>> So I'd be inclined to add those definitions in the pthread module,
>>> but if not we could define at the top of sort.c at least?
>>>
>>
>> The latter doesn't sound safe, since it would mean the files in
>> libcoreutils.a would be compiled without -D_THREAD_SAFE and would thus
>> access a global shared errno even when linked with sort.c. So I vote for
>> the former.
>>
>>
>

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Wed, 18 Jun 2014 20:59:47 +0200

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

Curious why you are calling this a compiler bug. I am not a POSIX nerd, but
it looks as if the old code was compiler independent, and now it is
dependent on something.

Just one difference in od.c that shows a change in identifer conventions.

What is the origin of the _GL_* identifiers? "Unix" or "Not Unix"?

from diff -u ./coreutils-8.20/src/od.c ./coreutils-8.22/src/od.c

@@ -1050,8 +1056,8 @@
 }

 static void
-format_address_none (uintmax_t address ATTRIBUTE_UNUSED,
-                     char c ATTRIBUTE_UNUSED)
+format_address_none (uintmax_t address _GL_UNUSED,
+                     char c _GL_UNUSED)
 {
 }

I also note that the identifiers involved go back to at least coreutils 8.9
in ./lib/ftoastr.h

So, this has been known, and managed, for a long time.

It is your code, so you can call it a bug if you wish - I am thinking, for
now, that it is a dependency on something not found by default when using
the xlc compilers. But I may be wrong :p <at> me


On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady <P <at> draigbrady.com> wrote:

> On 06/13/2014 02:38 PM, Michael Felt wrote:
>
> > make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
> >   CC       src/od.o
> > "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
> > _GL_FLT_PREC_BOUND.
>
> >   CC       src/getlimits.o
>
> > "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
> > _GL_LDBL_PREC_BOUND.
>
>
> I think Paul has already avoided this AIX compiler bug,
> and so this will be fixed in the upcoming coreutils-8.23
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6f053ff1
>
> thanks,
> Pádraig.
>

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Wed, 18 Jun 2014 21:16:04 +0200

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

I am confused by what is in git regarding ftoastr.h

The enum code has been around "forever" and not caused a problem. I think
the problem lies elsewhere because version 8.20 builds fine.

root <at> x093:[/data/prj/gnu/coreutils]diff ./coreutils-8.22/lib/ftoastr.h
./coreutils-8.15/lib/ftoastr.h
3c3
<    Copyright (C) 2010-2013 Free Software Foundation, Inc.
---
>    Copyright (C) 2010-2012 Free Software Foundation, Inc.

So, I do not understand the why the change to ftoastr.h is being
considered. The motivation that AIX compiler "has a bug" seems misleading
as this identifer has worked well for ftoast.c for many years.
The simple "include" of ftoastr.h to src/od.c and src/getlimits.c seems to
be making assumptions that ftoastr.c has not. So, maybe there is another
more elegant solution?


On Wed, Jun 18, 2014 at 8:59 PM, Michael Felt <mamfelt <at> gmail.com> wrote:

> Curious why you are calling this a compiler bug. I am not a POSIX nerd,
> but it looks as if the old code was compiler independent, and now it is
> dependent on something.
>
> Just one difference in od.c that shows a change in identifer conventions.
>
> What is the origin of the _GL_* identifiers? "Unix" or "Not Unix"?
>
> from diff -u ./coreutils-8.20/src/od.c ./coreutils-8.22/src/od.c
>
> @@ -1050,8 +1056,8 @@
>  }
>
>  static void
> -format_address_none (uintmax_t address ATTRIBUTE_UNUSED,
> -                     char c ATTRIBUTE_UNUSED)
> +format_address_none (uintmax_t address _GL_UNUSED,
> +                     char c _GL_UNUSED)
>  {
>  }
>
> I also note that the identifiers involved go back to at least coreutils
> 8.9 in ./lib/ftoastr.h
>
> So, this has been known, and managed, for a long time.
>
> It is your code, so you can call it a bug if you wish - I am thinking, for
> now, that it is a dependency on something not found by default when using
> the xlc compilers. But I may be wrong :p <at> me
>
>
> On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady <P <at> draigbrady.com> wrote:
>
>> On 06/13/2014 02:38 PM, Michael Felt wrote:
>>
>> > make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
>> >   CC       src/od.o
>> > "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
>> > _GL_FLT_PREC_BOUND.
>>
>> >   CC       src/getlimits.o
>>
>> > "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
>> > _GL_LDBL_PREC_BOUND.
>>
>>
>> I think Paul has already avoided this AIX compiler bug,
>> and so this will be fixed in the upcoming coreutils-8.23
>> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6f053ff1
>>
>> thanks,
>> Pádraig.
>>
>
>

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

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

From: Michael Felt <mamfelt <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>, 
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Wed, 18 Jun 2014 21:51:38 +0200

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

So, having looked at the -E output of the compiles I guess it has something
to do with how enum defines it results. And how that gets parsed here:

Goes over my head in any case.

#define _GL_FLOAT_STRLEN_BOUND_L(t, pointlen)                          \
  (1 + _GL_##t##_PREC_BOUND + pointlen + 1                             \
   + _GL_FLOAT_EXPONENT_STRLEN_BOUND (t##_MIN_10_EXP, t##_MAX_10_EXP))
#define  FLT_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L ( FLT,
pointlen)
#define  DBL_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L ( DBL,
pointlen)
#define LDBL_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L (LDBL,
pointlen)

/* Looser bounds that are locale-independent and are integral constant
   expressions.  */
#define  FLT_STRLEN_BOUND  FLT_STRLEN_BOUND_L (MB_LEN_MAX)
#define  DBL_STRLEN_BOUND  DBL_STRLEN_BOUND_L (MB_LEN_MAX)
#define LDBL_STRLEN_BOUND LDBL_STRLEN_BOUND_L (MB_LEN_MAX)

/* Looser, locale-independent bounds that include the trailing null byte.
*/
#define  FLT_BUFSIZE_BOUND ( FLT_STRLEN_BOUND + 1)
#define  DBL_BUFSIZE_BOUND ( DBL_STRLEN_BOUND + 1)
#define LDBL_BUFSIZE_BOUND (LDBL_STRLEN_BOUND + 1)

#endif /* _GL_FTOASTR_H */

Then in od.c we have this:
#define PRINT_FLOATTYPE(N, T, FTOASTR, BUFSIZE)                         \
  PRINT_FIELDS (N, T, fmt_string _GL_UNUSED,                      \
                char buf[BUFSIZE];                                      \
                FTOASTR (buf, sizeof buf, 0, 0, x);                     \
                xprintf ("%*s", adjusted_width, buf))

PRINT_TYPE (print_s_char, signed char)
PRINT_TYPE (print_char, unsigned char)
PRINT_TYPE (print_s_short, short int)
PRINT_TYPE (print_short, unsigned short int)
PRINT_TYPE (print_int, unsigned int)
PRINT_TYPE (print_long, unsigned long int)
PRINT_TYPE (print_long_long, unsigned_long_long_int)

PRINT_FLOATTYPE (print_float, float, ftoastr, FLT_BUFSIZE_BOUND)
PRINT_FLOATTYPE (print_double, double, dtoastr, DBL_BUFSIZE_BOUND)
PRINT_FLOATTYPE (print_long_double, long double, ldtoastr,
LDBL_BUFSIZE_BOUND)

which in od.i becomes (only the first PRINT_FLOATTYPE output), for
readability.

static void print_float (size_t fields, size_t blank, void const *block,
char const *fmt_string, int width, int pad) { float const *p = block;
uintmax_t i;
 int pad_remaining = pad; for (i = fields; blank < i; i--) { int next_pad =
pad * (i - 1) / fields; int adjusted_width = pad_remaining - next_pad +
width;
float x = *p++; char buf[( (1 + _GL_FLT_PREC_BOUND + 4 + 1 + ( -100 < (-37)
&& (38) < 100 ? 3 : -1000 < (-37) && (38) < 1000 ? 4 : -10000 < (-37) &&
(38) <
 10000 ? 5 : -100000 < (-37) && (38) < 100000 ? 6 : -1000000 < (-37) &&
(38) < 1000000 ? 7 : ((((sizeof (int) * (8) - (! ((__typeof__ (int)) 0 <
(__typeof_
_ (int)) -1))) * 146 + 484) / 485) + (! ((__typeof__ (int)) 0 < (__typeof__
(int)) -1))) )) + 1)]; ftoastr (buf, sizeof buf, 0, 0, x); xprintf ("%*s",
adju
sted_width, buf); pad_remaining = next_pad; } }

Aren't macros fun!

Anyway, if this is the "workings" of the bug, then maybe I can get it
submitted for a bugfix.

So, before I do any try and submit a bugreport to IBM - please verify that
the above is "the bug" - perhaps showing how your compiler completes the
"od.i" code.

Michael


On Wed, Jun 18, 2014 at 9:16 PM, Michael Felt <mamfelt <at> gmail.com> wrote:

> I am confused by what is in git regarding ftoastr.h
>
> The enum code has been around "forever" and not caused a problem. I think
> the problem lies elsewhere because version 8.20 builds fine.
>
> root <at> x093:[/data/prj/gnu/coreutils]diff ./coreutils-8.22/lib/ftoastr.h
> ./coreutils-8.15/lib/ftoastr.h
> 3c3
> <    Copyright (C) 2010-2013 Free Software Foundation, Inc.
> ---
> >    Copyright (C) 2010-2012 Free Software Foundation, Inc.
>
> So, I do not understand the why the change to ftoastr.h is being
> considered. The motivation that AIX compiler "has a bug" seems misleading
> as this identifer has worked well for ftoast.c for many years.
> The simple "include" of ftoastr.h to src/od.c and src/getlimits.c seems to
> be making assumptions that ftoastr.c has not. So, maybe there is another
> more elegant solution?
>
>
> On Wed, Jun 18, 2014 at 8:59 PM, Michael Felt <mamfelt <at> gmail.com> wrote:
>
>> Curious why you are calling this a compiler bug. I am not a POSIX nerd,
>> but it looks as if the old code was compiler independent, and now it is
>> dependent on something.
>>
>> Just one difference in od.c that shows a change in identifer conventions.
>>
>> What is the origin of the _GL_* identifiers? "Unix" or "Not Unix"?
>>
>> from diff -u ./coreutils-8.20/src/od.c ./coreutils-8.22/src/od.c
>>
>> @@ -1050,8 +1056,8 @@
>>  }
>>
>>  static void
>> -format_address_none (uintmax_t address ATTRIBUTE_UNUSED,
>> -                     char c ATTRIBUTE_UNUSED)
>> +format_address_none (uintmax_t address _GL_UNUSED,
>> +                     char c _GL_UNUSED)
>>  {
>>  }
>>
>> I also note that the identifiers involved go back to at least coreutils
>> 8.9 in ./lib/ftoastr.h
>>
>> So, this has been known, and managed, for a long time.
>>
>> It is your code, so you can call it a bug if you wish - I am thinking,
>> for now, that it is a dependency on something not found by default when
>> using the xlc compilers. But I may be wrong :p <at> me
>>
>>
>> On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady <P <at> draigbrady.com> wrote:
>>
>>> On 06/13/2014 02:38 PM, Michael Felt wrote:
>>>
>>> > make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
>>> >   CC       src/od.o
>>> > "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
>>> > _GL_FLT_PREC_BOUND.
>>>
>>> >   CC       src/getlimits.o
>>>
>>> > "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
>>> > _GL_LDBL_PREC_BOUND.
>>>
>>>
>>> I think Paul has already avoided this AIX compiler bug,
>>> and so this will be fixed in the upcoming coreutils-8.23
>>> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6f053ff1
>>>
>>> thanks,
>>> Pádraig.
>>>
>>
>>
>

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Felt <mamfelt <at> gmail.com>, Pádraig Brady
 <P <at> draigbrady.com>
Cc: 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Wed, 18 Jun 2014 15:25:55 -0700

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

Michael Felt wrote:
> Curious why you are calling this a compiler bug.

Because it is a compiler bug.  Try to compile (but not link) the 
attached file.  Here's what I get on AIX 7.1 with xlc 12.1 and GCC 4.8.1.

$ gcc -c xlcbug1.c
$ xlc -c xlcbug1.c
"xlcbug1.c", line 22.39: 1506-045 (S) Undeclared identifier 
GL_FLT_PREC_BOUND.
"xlcbug1.c", line 22.23: 1506-1324 (S) Array size must have integer type.

There's nothing wrong with the program.  The identifier is properly 
declared.

> What is the origin of the _GL_* identifiers?

They're from Gnulib, but that's irrelevant to the compiler bug, as the 
attached file demonstrates.

[xlcbug1.c (text/x-csrc, attachment)]

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

From: Michael Felt <mamfelt <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17773 <at> debbugs.gnu.org
Subject: Re: bug#17773: AIX build errors with coreutils-8.22
Date: Sat, 21 Jun 2014 12:11:59 +0200

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

Thanks for the update.



On Thu, Jun 19, 2014 at 12:25 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> Michael Felt wrote:
>
>> Curious why you are calling this a compiler bug.
>>
>
> Because it is a compiler bug.  Try to compile (but not link) the attached
> file.  Here's what I get on AIX 7.1 with xlc 12.1 and GCC 4.8.1.
>
> $ gcc -c xlcbug1.c
> $ xlc -c xlcbug1.c
> "xlcbug1.c", line 22.39: 1506-045 (S) Undeclared identifier
> GL_FLT_PREC_BOUND.
> "xlcbug1.c", line 22.23: 1506-1324 (S) Array size must have integer type.
>
> There's nothing wrong with the program.  The identifier is properly
> declared.
>
>
>  What is the origin of the _GL_* identifiers?
>>
>
> They're from Gnulib, but that's irrelevant to the compiler bug, as the
> attached file demonstrates.
>

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

Previous Next

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