AIX Hints file change

[p5pRT]

Migrated from rt.perl.org#113778 (status was 'resolved')

Searchable as RT113778$

[p5pRT]

From @dmcbride

Created by @dmcbride

When compiling many of the perl modules available from CPAN\, an expectation of C99 support seems implied by many authors. Unfortunately\, xlC doesn't do this by default\, we have to add -qlanglvl=extc99 to the ccflags to get this to work. And by the time we get to installing modules\, this flag is already set in Config.

If I add "-Accflags=-qlanglvl=extc99" to my Configure command line (see below)\, then all 56 modules in my list compile more or less without issue. Some are pure-perl\, some are XS\, and some of those fail without this option.

Obviously\, this doesn't affect perl itself\, as it seems to rely solely on the C89 standard. However\, this can make the out-of-box experience on AIX w/xlC that much better by allowing CPAN to Just Work (TM).

Perl Info

``` Flags: category=install severity=low Site configuration information for perl 5.16.0: Configured by dmcbride at Wed Jun 20 19:12:29 EDT 2012. Summary of my perl5 (revision 5 version 16 subversion 0) configuration: Platform: osname=aix, osvers=6.1.0.0, archname=aix-thread-multi-64all uname='aix hotelisasp01 1 6 00c1837d4c00 ' config_args='-desr -Accflags=-qlanglvl=extc99 -Duse64bitall -Duselongdoubles -Dusethreads -Duserelocatableinc -Dman1direxp= -Dman3direxp= - Dprefix=/opt/appl/mi/perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc -q64', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE - qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -qlanglvl=extc99 - DNEED_PTHREAD_INIT -q64 -DUSE_64_BIT_ALL -q64', optimize='-O', cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 - qnoansialias -DUSE_NATIVE_DLOPEN -qlanglvl=extc99 -DNEED_PTHREAD_INIT' ccversion='10.1.0.2', gccversion='', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='ld', ldflags ='-brtl -bdynamic -L/usr/local/lib -b64' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lbind -lnsl -ldbm -ldl -lld -lm -lcrypt -lpthreads -lc perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc libc=, so=a, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags=' - bE:.../../lib/5.16.0/aix-thread-multi-64all/CORE/perl.exp' cccdlflags=' ', lddlflags='-b64 -bhalt:4 -G -bI:$(PERL_INC)/perl.exp -bE: $(BASEEXT).exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib' Locally applied patches: @INC for perl 5.16.0: /home/dmcbride/tmp/isas/perl/opt/appl/mi/perl/lib/site_perl/5.16.0/aix- thread-multi-64all /home/dmcbride/tmp/isas/perl/opt/appl/mi/perl/lib/site_perl/5.16.0 /home/dmcbride/tmp/isas/perl/opt/appl/mi/perl/lib/5.16.0/aix-thread- multi-64all /home/dmcbride/tmp/isas/perl/opt/appl/mi/perl/lib/5.16.0 . Environment for perl 5.16.0: HOME=/home/dmcbride LANG=en_US LANGUAGE (unset) LC__FASTMSG=true LD_LIBRARY_PATH (unset) LIBPATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/dmcbride/bin:/usr/bin/X11:/sbin:/usr/opt/perl5/bin PERL_BADLANG (unset) SHELL=/usr/bin/bash ```

[p5pRT]

From @tux

On Thu\, 21 Jun 2012 10​:40​:39 -0700\, Darin McBride (via RT) \perlbug\-followup@​perl\.org wrote​:

When compiling many of the perl modules available from CPAN\, an expectation of C99 support seems implied by many authors. Unfortunately\, xlC doesn't do this by default\, we have to add -qlanglvl=extc99 to the ccflags to get this to work. And by the time we get to installing modules\, this flag is already set in Config.

If I add "-Accflags=-qlanglvl=extc99" to my Configure command line (see below)\, then all 56 modules in my list compile more or less without issue. Some are pure-perl\, some are XS\, and some of those fail without this option.

Obviously\, this doesn't affect perl itself\, as it seems to rely solely on the C89 standard. However\, this can make the out-of-box experience on AIX w/xlC that much better by allowing CPAN to Just Work (TM).

I'm two-fold on this. Perl itself clearly states that C89 ir required.

IMHO CPAN authors should respect that and not use C99. Most of the time it is either ignorance or plain bluntness. I really think CPAN authors SHOULD restrict to C89 or explicitely say otherwise in the README and Makefile.PL or Build.PL that they deliberately break this on purpose.

OTOH xlc support (limited) C99 for a (very) long time\, and adding those options to the hints might be friendly to the users.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @dmcbride

On Thursday June 21 2012 10​:53​:58 AM you wrote​:

I'm two-fold on this. Perl itself clearly states that C89 ir required.

Quoth INSTALL​:

A minimum of C89 is required. Some features available in C99 will be probed for and used when found. The perl build process does not rely on anything more than C89.

It's clear that C89 is required. C99 fulfills this. It's also clear that C99 will be used when found (in some limited respect). It's not clear what features those are should a module author want to rely on it.

It's also clear that the *perl* build process only uses C89. It's not clear that additional modules you get from CPAN also only rely on C89. :-)

IMHO CPAN authors should respect that and not use C99. Most of the time it is either ignorance or plain bluntness. I really think CPAN authors SHOULD restrict to C89 or explicitely say otherwise in the README and Makefile.PL or Build.PL that they deliberately break this on purpose.

Yeah\, well\, on HPUX\, you can set your requirements as you like. On a real platform\, however ...

*duck*

:-)))))))

(Let's leave the above C89/C99 opinion as we've left our AIX vs HPUX opinions​: agreement to disagree.)

OTOH xlc support (limited) C99 for a (very) long time\, and adding those options to the hints might be friendly to the users.

And that's basically where this comes from. Whether modules should or should not be using C99 (or C09 or C19...)\, the reality is\, some are. Do we go down the path of​:

a) denial or trying to herd cats to get all module authors to conform to C89 when some authors have their own view of the ideal world are are unwilling to budge\, b) adding something to the README.aix file to indicate that the "-Accflags=- qlanglvl=extc99" parameter to Configure may help in getting some modules to install at a later date\, or c) just add it to the AIX hints for xlC.

Personally\, I think (a) is a lost cause\, and that (c) is both easier than (b) and more user-friendly.

[p5pRT]

From @ikegami

On Thu\, Jun 21\, 2012 at 1​:53 PM\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote​:

I'm two-fold on this. Perl itself clearly states that C89 ir required.

Not so.

A minimum of C89 is required. Some features available in C99 will be probed for and used when found. The perl build process does not rely on anything more than C89.

[p5pRT]

From @tux

On Thu\, 21 Jun 2012 12​:08​:40 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

On Thursday June 21 2012 10​:53​:58 AM you wrote​:

I'm two-fold on this. Perl itself clearly states that C89 ir required.

Quoth INSTALL​:

A minimum of C89 is required. Some features available in C99 will be probed for and used when found. The perl build process does not rely on anything more than C89.

It's clear that C89 is required. C99 fulfills this. It's also clear that C99 will be used when found (in some limited respect). It's not clear what features those are should a module author want to rely on it.

additional clearance welcome?

It's also clear that the *perl* build process only uses C89. It's not clear that additional modules you get from CPAN also only rely on C89. :-)

I would argue that we should motivate CPAN authors to restrict to the minimal requirements more clearly. They could loose users otherwise

IMHO CPAN authors should respect that and not use C99. Most of the time it is either ignorance or plain bluntness. I really think CPAN authors SHOULD restrict to C89 or explicitely say otherwise in the README and Makefile.PL or Build.PL that they deliberately break this on purpose.

Yeah\, well\, on HPUX\, you can set your requirements as you like. On a real platform\, however ...

*duck*

:-)))))))

Note that we both know that you are joking. We both have out preferences and we both will admit that both AIX and HP-UX have their specific merits. AIX clearly wins on its ile system and smitty (vs sam) HP-UX clearly wins on libraries\, open-source support and disk locations

BOTH clearly win against OSF/1

The C-compiler on AIX is picky but fast - on all OS releases. The C compiler on HP-UX is less picky but extremely informative on Itanium just as fast as AIX' compiler and just as expensive. AIX' precompiler still sucks. HP-UX' shell commands are - in my experience - about 10 times as fast as AIX'. Configure therefor is a lot faster on HP-UX. HP's C-ANSI-C has options to select C99\, just as most other expensive propriatary compilers\, but they never implemented them for extinct OS versions like HP-UX 10.20\, which I still support for building pel on. There are many people that state C99 is now already X years old and we should move forward. If p5p would take that decision I can live with that but it will drop support for compilers that we currently still support with relatively less effort.

For *runtime* perl I spot no difference at all. Both very well support 64bit and 3rd party libraries like Oracle and Postgres. Both serve a specific public/audience\, which in my experience quite often is not aimed at the end-users but controlled by the IT staff who are either anti-IBM or anti-HP and seldom choose for either because of the OS or its features but for best deal and/or best support. Fact​: we lost a client (on IBM hardware) because their new IT manager was fired at IBM and therefor decided that all the (IBM) hardware at the client side was to be replaced with Windows. We didn't then support our applications on Windows and thus lost the client. The end users were never even consulted.

(Let's leave the above C89/C99 opinion as we've left our AIX vs HPUX opinions​: agreement to disagree.)

OTOH xlc support (limited) C99 for a (very) long time\, and adding those options to the hints might be friendly to the users.

And that's basically where this comes from. Whether modules should or should not be using C99 (or C09 or C19...)\, the reality is\, some are. Do we go down the path of​:

a) denial or trying to herd cats to get all module authors to conform to C89 when some authors have their own view of the ideal world are are unwilling to budge\, b) adding something to the README.aix file to indicate that the "-Accflags=- qlanglvl=extc99" parameter to Configure may help in getting some modules to install at a later date\, or c) just add it to the AIX hints for xlC.

Personally\, I think (a) is a lost cause\, and that (c) is both easier than (b) and more user-friendly.

Go for c) I do not remember if AIX-4's xlc also supported C99\, but aix4 has officially been dropped iirc (though hints/ still has aix-3 and aix4)

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @timj

On Thu\, Jun 21\, 2012 at 11​:37 PM\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote​:

On Thu\, 21 Jun 2012 12​:08​:40 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

It's also clear that the *perl* build process only uses C89.  It's not clear that additional modules you get from CPAN also only rely on C89. :-)

I would argue that we should motivate CPAN authors to restrict to the minimal requirements more clearly. They could loose users otherwise

but how do I know whether a particular platform is c99 or c89? I'm running into a problem on CPAN testers at the moment because solaris builds there don't enable c99. I rely on the copysign() math function (I need to detect -0.0) and the hacks to get it working on c89 are not pretty and make the code less robust.

I'd like to use copysign on platforms that use c99 but otherwise use the fallback. Ideally I could just look in $Config{is_c99} and enable a -D option for the build. Currently I am faced with globally going to the fallback when ^O is 'solaris' but that seems to be a bit unfair for solaris users that turn on the c99 compiler switch.

-- Tim Jenness

[p5pRT]

From @tux

On Fri\, 22 Jun 2012 06​:57​:22 -0700\, Tim Jenness \tim\.jenness@​gmail\.com wrote​:

On Thu\, Jun 21\, 2012 at 11​:37 PM\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote​:

On Thu\, 21 Jun 2012 12​:08​:40 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

It's also clear that the *perl* build process only uses C89.  It's not clear that additional modules you get from CPAN also only rely on C89. :-)

I would argue that we should motivate CPAN authors to restrict to the minimal requirements more clearly. They could loose users otherwise

but how do I know whether a particular platform is c99 or c89? I'm running into a problem on CPAN testers at the moment because solaris builds there don't enable c99. I rely on the copysign() math function (I need to detect -0.0) and the hacks to get it working on c89 are not pretty and make the code less robust.

I'd like to use copysign on platforms that use c99 but otherwise use the fallback. Ideally I could just look in $Config{is_c99} and enable a -D option for the build. Currently I am faced with globally going to the fallback when ^O is 'solaris' but that seems to be a bit unfair for solaris users that turn on the c99 compiler switch.

Good point. Note however that $^O is by no means a reliable switch to see if the development environment is C99\, as the OS doesn't define C99 support\, but the compiler does (sometimes in combination with available libraries or library functions).

Furthermore is the fact that a compiler claims to be C99 by no means a guarantee that the compiler supports all of C99\, so IMHO is_C99 is a nogo as it suggests more than there might actually be available. But wait\, there is more!

Support perl was built with XXc-1.2.3 (any ANSI C compiler with C99 for this specific OS/Arch) and all goes well\, but the end-user that uses CPAN (with XS) to install some additional module that requires C99 and uses XXc-1.2.1 that does pretend to support C99 but doesn't support it at well as 1.2.3 does. is_C99 would now be a complete lie.

C99 is about both functions\, like copysign ()\, and syntax\, like the dreaded c++ comments (//).

Your situation is a good example of why a CPAN author would choose to require C99. Wanting C99 just for // comments imho is not.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @timj

On Fri\, Jun 22\, 2012 at 7​:16 AM\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote​:

On Fri\, 22 Jun 2012 06​:57​:22 -0700\, Tim Jenness \tim\.jenness@​gmail\.com wrote​:

On Thu\, Jun 21\, 2012 at 11​:37 PM\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote​:

On Thu\, 21 Jun 2012 12​:08​:40 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

It's also clear that the *perl* build process only uses C89.  It's not clear that additional modules you get from CPAN also only rely on C89. :-)

I would argue that we should motivate CPAN authors to restrict to the minimal requirements more clearly. They could loose users otherwise

but how do I know whether a particular platform is c99 or c89? I'm running into a problem on CPAN testers at the moment because solaris builds there don't enable c99. I rely on the copysign() math function (I need to detect -0.0) and the hacks to get it working on c89 are not pretty and make the code less robust.

I'd like to use copysign on platforms that use c99 but otherwise use the fallback. Ideally I could just look in $Config{is_c99} and enable a -D option for the build. Currently I am faced with globally going to the fallback when ^O is 'solaris' but that seems to be a bit unfair for solaris users that turn on the c99 compiler switch.

Good point. Note however that $^O is by no means a reliable switch to see if the development environment is C99\, as the OS doesn't define C99 support\, but the compiler does (sometimes in combination with available libraries or library functions).

Sure\, but if I want my module to pass cpan testing but still retain the robust version of the code on most platforms I don't think I have a choice but to check $^O.

-- Tim Jenness

[p5pRT]

From @Leont

On Fri\, Jun 22\, 2012 at 3​:57 PM\, Tim Jenness \tim\.jenness@​gmail\.com wrote​:

but how do I know whether a particular platform is c99 or c89? I'm running into a problem on CPAN testers at the moment because solaris builds there don't enable c99. I rely on the copysign() math function (I need to detect -0.0) and the hacks to get it working on c89 are not pretty and make the code less robust.

There's the __STDC_VERSION__ define\, which should be 199901L (or higher) if C99 is supported. No idea if this is reliable or not though.

Leon

[p5pRT]

From @dmcbride

On Thursday June 21 2012 11​:38​:09 PM you wrote​:

Quoth INSTALL​:

A minimum of C89 is required. Some features available in C99 will be probed for and used when found. The perl build process does not rely on anything more than C89.

It's clear that C89 is required. C99 fulfills this. It's also clear that C99 will be used when found (in some limited respect). It's not clear what features those are should a module author want to rely on it.

additional clearance welcome?

Yeah\, I don't know what perl will use from C99\, either\, nor really what to look for. I more or less stopped doing C (and doing shell/perl) before C99 was widely available (2000/2001)\, so didn't really get into that.

Note that we both know that you are joking.

Joking? More like "teasing" :-)

its features but for best deal and/or best support. Fact​: we lost a client (on IBM hardware) because their new IT manager was fired at IBM and therefor decided that all the (IBM) hardware at the client side was to be replaced with Windows. We didn't then support our applications on Windows and thus lost the client. The end users were never even consulted.

Yeah\, that one I'm not going to understand. Allowing a new IT manager to make such a drastic decision without detailed cost/benefit analysis confuses me. :-)
(And "I was fired by one vendor\, so I don't want to use their products anymore" isn't a benefit. :-P)

c) just add it to the AIX hints for xlC.

Personally\, I think (a) is a lost cause\, and that (c) is both easier than (b) and more user-friendly.

Go for c)

Trying. Though I admit some confusion.

I do not remember if AIX-4's xlc also supported C99\, but aix4 has officially been dropped iirc (though hints/ still has aix-3 and aix4)

Maybe those should be removed\, too\, just as a general cleanup concept :-)

So\, here's the aix.sh changes\, at least so far. I don't want to touch gcc as I presume it does c99 by default.

Inline Patch

```diff diff --git a/hints/aix.sh b/hints/aix.sh index 63f245f..e1ae2fd 100644 --- a/hints/aix.sh +++ b/hints/aix.sh @@ -96,7 +96,7 @@ cc=${cc:-cc} ccflags="$ccflags -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE" case "$cc" in *gcc*) ;; - *) ccflags="$ccflags -qmaxmem=-1 -qnoansialias" ;; + *) ccflags="$ccflags -qmaxmem=-1 -qnoansialias -qlanglvl=extc99" ;; esac nm_opt='-B' @@ -245,13 +245,9 @@ case "$usethreads" in cc_r) ;; xlc_r) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" ;; # we do not need the C++ compiler xlC_r) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" cc=xlc_r ;; '') @@ -272,13 +268,9 @@ case "$usethreads" in *) case "$cc" in xlc) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" ;; # we do not need the C++ compiler xlC) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" cc=xlc ;; *) @@ -348,6 +340,9 @@ libswanted_uselargefiles="`getconf XBS5_ILP32_OFFBIG_LIBS ```

2>/dev/null|sed -e 's@   $define|true|[yY]*) cc="$cc -q64" ;;   *) cc="$cc -q32" ;;   esac + # Some 32-bit getconfs will set ccflags to include -qlonglong + # but that's no longer needed with an explicit -qextc99. + ccflags="`echo $ccflags | sed -e 's@​ -qlonglong@​@​`"   ;;   *) # Remove xlc-specific -qflags.   ccflags="`echo $ccflags | sed -e 's@​ -q[^ ]*@​ @​g' -e 's@​^-q[^ ]* @​@​g'`"

And here's where it gets confusing. For some reason\, the -bE​: shows up twice\, at least in this test. But only when I'm compiling for 64-bit\, not 32-bit.
I'm going to keep looking for the root cause\, though this works around it for now (I don't think it's a problem per se at runtime as both -bE​:'s point to where perl is about to be installed). If anyone has an idea here that can help\, 'twould be appreciated.

Inline Patch

```diff diff --git a/lib/ExtUtils/t/Embed.t b/lib/ExtUtils/t/Embed.t index 269b20a..fda66a1 100644 --- a/lib/ExtUtils/t/Embed.t +++ b/lib/ExtUtils/t/Embed.t @@ -95,7 +95,7 @@ if ($^O eq 'VMS') { my ($perl_exp) = grep { -f } qw(perl.exp ../perl.exp); die "where is perl.exp?\n" unless defined $perl_exp; for (@cmd) { - s!-bE:(\S+)!-bE:$perl_exp!; + s!-bE:(\S+)!-bE:$perl_exp!g; } } elsif ($^O eq 'cygwin') { # Cygwin needs no special treatment like below ```

[p5pRT]

From @dmcbride

On Sun Jun 24 06​:50​:40 2012\, dmcbride@​cpan.org wrote​:

And here's where it gets confusing. For some reason\, the -bE​: shows up twice\, at least in this test. But only when I'm compiling for 64-bit\, not 32-bit.

And now I can't figure out how to reproduce it. :-( So\, this part of the patch is no longer required\, though the only thing worse than problems that show up unexpectedly is problems that go away unexpectedly.

[p5pRT]

From @dmcbride

Ok\, I think my earlier problem came from not cleaning up properly between multiple compiles. So I don't need to modify any test.

Proposed log entry​:

When compiling many of the perl modules available from CPAN\, an expectation of C99 support seems implied by many authors. Unfortunately\, xlC doesn't do this by default\, we have to add -qlanglvl=extc99 to the ccflags to get this to work. And by the time we get to installing modules\, this flag is already set in Config.

So\, add the flag unconditionally at the outset. Also\, remove -qlonglong and -qlanglvl=extended from the flags to silence the warning that extc99 includes them and that xlC is going to ignore it\, using extc99 instead.

[p5pRT]

From @dmcbride

aix-extc99.patch

```diff diff --git a/hints/aix.sh b/hints/aix.sh index 63f245f..e1ae2fd 100644 --- a/hints/aix.sh +++ b/hints/aix.sh @@ -96,7 +96,7 @@ cc=${cc:-cc} ccflags="$ccflags -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE" case "$cc" in *gcc*) ;; - *) ccflags="$ccflags -qmaxmem=-1 -qnoansialias" ;; + *) ccflags="$ccflags -qmaxmem=-1 -qnoansialias -qlanglvl=extc99" ;; esac nm_opt='-B' @@ -245,13 +245,9 @@ case "$usethreads" in cc_r) ;; xlc_r) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" ;; # we do not need the C++ compiler xlC_r) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" cc=xlc_r ;; '') @@ -272,13 +268,9 @@ case "$usethreads" in *) case "$cc" in xlc) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" ;; # we do not need the C++ compiler xlC) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" cc=xlc ;; *) @@ -348,6 +340,9 @@ libswanted_uselargefiles="`getconf XBS5_ILP32_OFFBIG_LIBS 2>/dev/null|sed -e 's@ $define|true|[yY]*) cc="$cc -q64" ;; *) cc="$cc -q32" ;; esac + # Some 32-bit getconfs will set ccflags to include -qlonglong + # but that's no longer needed with an explicit -qextc99. + ccflags="`echo $ccflags | sed -e 's@ -qlonglong@@`" ;; *) # Remove xlc-specific -qflags. ccflags="`echo $ccflags | sed -e 's@ -q[^ ]*@ @g' -e 's@^-q[^ ]* @@g'`" ```

[p5pRT]

From @cpansprout

On Sun Jun 24 06​:50​:40 2012\, dmcbride@​cpan.org wrote​:

So\, here's the aix.sh changes\, at least so far. I don't want to touch gcc as I presume it does c99 by default.

diff --git a/hints/aix.sh b/hints/aix.sh index 63f245f..e1ae2fd 100644 --- a/hints/aix.sh +++ b/hints/aix.sh @​@​ -96\,7 +96\,7 @​@​ cc=${cc​:-cc} ccflags="$ccflags -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE" case "$cc" in *gcc*) ;; - *) ccflags="$ccflags -qmaxmem=-1 -qnoansialias" ;; + *) ccflags="$ccflags -qmaxmem=-1 -qnoansialias -qlanglvl=extc99" ;; esac nm_opt='-B'

@​@​ -245\,13 +245\,9 @​@​ case "$usethreads" in cc_r) ;; xlc_r) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" ;; # we do not need the C++ compiler xlC_r) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" cc=xlc_r ;; '') @​@​ -272\,13 +268\,9 @​@​ case "$usethreads" in *) case "$cc" in xlc) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" ;; # we do not need the C++ compiler xlC) - # for -qlonglong - ccflags="$ccflags -qlanglvl=extended" cc=xlc ;; *) @​@​ -348\,6 +340\,9 @​@​ libswanted_uselargefiles="`getconf XBS5_ILP32_OFFBIG_LIBS 2>/dev/null|sed -e 's@​ $define|true|[yY]*) cc="$cc -q64" ;; *) cc="$cc -q32" ;; esac + # Some 32-bit getconfs will set ccflags to include -qlonglong + # but that's no longer needed with an explicit -qextc99. + ccflags="`echo $ccflags | sed -e 's@​ -qlonglong@​@​`" ;; *) # Remove xlc-specific -qflags. ccflags="`echo $ccflags | sed -e 's@​ -q[^ ]*@​ @​g' -e 's@​^-q[^ ]* @​@​g'`"

And here's where it gets confusing. For some reason\, the -bE​: shows up twice\, at least in this test. But only when I'm compiling for 64-bit\, not 32-bit. I'm going to keep looking for the root cause\, though this works around it for now (I don't think it's a problem per se at runtime as both -bE​:'s point to where perl is about to be installed). If anyone has an idea here that can help\, 'twould be appreciated.

diff --git a/lib/ExtUtils/t/Embed.t b/lib/ExtUtils/t/Embed.t index 269b20a..fda66a1 100644 --- a/lib/ExtUtils/t/Embed.t +++ b/lib/ExtUtils/t/Embed.t @​@​ -95\,7 +95\,7 @​@​ if ($^O eq 'VMS') { my ($perl_exp) = grep { -f } qw(perl.exp ../perl.exp); die "where is perl.exp?\n" unless defined $perl_exp; for (@​cmd) { - s!-bE​:(\S+)!-bE​:$perl_exp!; + s!-bE​:(\S+)!-bE​:$perl_exp!g; } } elsif ($^O eq 'cygwin') { # Cygwin needs no special treatment like below

Is the hints patch dependent on the test change? There is enough going on in this ticket that I am confused.

--

Father Chrysostomos

[p5pRT]

From @dmcbride

On Tuesday June 26 2012 9​:27​:00 AM Father Chrysostomos via RT wrote​:

Is the hints patch dependent on the test change? There is enough going on in this ticket that I am confused.

Originally\, I thought it was related. But\, as I added to the thread later\, I think the test change was due to an unclean build environment. When I started to use rsync to delete extraneous files (from a clean git environment)\, the problem went away.

Basically\, if you build a 64-bit perl\, run make realclean\, and then try building a 32-bit perl\, sometimes it's not clean enough. :-) "git clean -fdx" helps\, but I don't have git on the AIX machine\, so I updated my rsync script to add --del\, and suddenly all the extra files went away. And now I can't reproduce.

So\, no\, I think we're good with just the hints patch. :-) (If Tux is willing to put on some sunglasses to protect his eyes and give this a look-over\, too\, that'd be appreciated.)

[p5pRT]

From @tux

On Tue\, 26 Jun 2012 10​:33 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

On Tuesday June 26 2012 9​:27​:00 AM Father Chrysostomos via RT wrote​:

Is the hints patch dependent on the test change? There is enough going on in this ticket that I am confused.

Originally\, I thought it was related. But\, as I added to the thread later\, I think the test change was due to an unclean build environment. When I started to use rsync to delete extraneous files (from a clean git environment)\, the problem went away.

Basically\, if you build a 64-bit perl\, run make realclean\, and then try building a 32-bit perl\, sometimes it's not clean enough. :-) "git clean -fdx" helps\, but I don't have git on the AIX machine\, so I updated my rsync script to add --del\, and suddenly all the extra files went away. And now I can't reproduce.

So\, no\, I think we're good with just the hints patch. :-) (If Tux is willing to put on some sunglasses to protect his eyes and give this a look-over\, too\, that'd be appreciated.)

I even tried to apply as it looks perfectly sane\, but I was unable to Configure foir whatever reason and $work is needing my tuits

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @tux

On Tue\, 26 Jun 2012 19​:24​:12 +0200\, "H.Merijn Brand" \h\.m\.brand@​xs4all\.nl wrote​:

On Tue\, 26 Jun 2012 10​:33 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

On Tuesday June 26 2012 9​:27​:00 AM Father Chrysostomos via RT wrote​:

Is the hints patch dependent on the test change? There is enough going on in this ticket that I am confused.

Originally\, I thought it was related. But\, as I added to the thread later\, I think the test change was due to an unclean build environment. When I started to use rsync to delete extraneous files (from a clean git environment)\, the problem went away.

Basically\, if you build a 64-bit perl\, run make realclean\, and then try building a 32-bit perl\, sometimes it's not clean enough. :-) "git clean -fdx" helps\, but I don't have git on the AIX machine\, so I updated my rsync script to add --del\, and suddenly all the extra files went away. And now I can't reproduce.

So\, no\, I think we're good with just the hints patch. :-) (If Tux is willing to put on some sunglasses to protect his eyes and give this a look-over\, too\, that'd be appreciated.)

I even tried to apply as it looks perfectly sane\, but I was unable to Configure for whatever reason and $work is needing my tuits

Now fixed. Applied as 9d7bf48eff0f88f

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @tux

On Wed\, 27 Jun 2012 08​:34​:49 +0200\, "H.Merijn Brand" \h\.m\.brand@​xs4all\.nl wrote​:

On Tue\, 26 Jun 2012 19​:24​:12 +0200\, "H.Merijn Brand" \h\.m\.brand@​xs4all\.nl wrote​:

On Tue\, 26 Jun 2012 10​:33 -0600\, Darin McBride \dmcbride@​cpan\.org wrote​:

I just applied the hints change. Changes to README.aix and delta entries are still welcomed.

Your eyes would be appreciated on the current content of README.aix\, for which some content might by now be invalid or at least outdated.

On Tuesday June 26 2012 9​:27​:00 AM Father Chrysostomos via RT wrote​:

Is the hints patch dependent on the test change? There is enough going on in this ticket that I am confused.

Originally\, I thought it was related. But\, as I added to the thread later\, I think the test change was due to an unclean build environment. When I started to use rsync to delete extraneous files (from a clean git environment)\, the problem went away.

Basically\, if you build a 64-bit perl\, run make realclean\, and then try building a 32-bit perl\, sometimes it's not clean enough. :-) "git clean -fdx" helps\, but I don't have git on the AIX machine\, so I updated my rsync script to add --del\, and suddenly all the extra files went away. And now I can't reproduce.

So\, no\, I think we're good with just the hints patch. :-) (If Tux is willing to put on some sunglasses to protect his eyes and give this a look-over\, too\, that'd be appreciated.)

I even tried to apply as it looks perfectly sane\, but I was unable to Configure for whatever reason and $work is needing my tuits

Now fixed. Applied as 9d7bf48eff0f88f

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'

[p5pRT]

From @nwc10

On Fri\, Jun 22\, 2012 at 08​:59​:03PM +0200\, Leon Timmermans wrote​:

On Fri\, Jun 22\, 2012 at 3​:57 PM\, Tim Jenness \tim\.jenness@​gmail\.com wrote​:

but how do I know whether a particular platform is c99 or c89? I'm running into a problem on CPAN testers at the moment because solaris builds there don't enable c99. I rely on the copysign() math function (I need to detect -0.0) and the hacks to get it working on c89 are not pretty and make the code less robust.

There's the __STDC_VERSION__ define\, which should be 199901L (or higher) if C99 is supported. No idea if this is reliable or not though.

For example​:

$ gcc-mp-4.7 -std=c99 -dM -E - \</dev/null | grep STD #define __STDC_HOSTED__ 1 #define __STDC_VERSION__ 199901L #define __GNUC_STDC_INLINE__ 1 #define __STDC__ 1

and yet http​://en.wikipedia.org/wiki/C99#Implementations and http​://gcc.gnu.org/gcc-4.7/c99status.html both state that conformance is not complete.

I suspect that in the real world\, it's going to be necessary to probe for C99 feature availability forever.

Nicholas Clark