Boost fails to compile on AIX 6.1 with IBM XL C/C++ V10.01

[cpaolino@…]

Hi,

I'm trying to compile Boost 1.44.0 on a IBM P575 Power6 cluster with XL 10.01 but got a lot of errors, especially regarding Math, Python and Xpressive.

While I don't care much about Math and Python, Xpressive is a dependency of graph readers (and other stuff) in the (Parallel) Boost Graph Library, a key component of our application.

The failed build log will follow.

Any help will be appreciated, thanks in advance.

[cpaolino@…]

Failed build log

[Michael Haubenwallner <michael.haubenwallner@…>]

Same problems here on AIX 6.1, although using gcc:

    "g++"  -ftemplate-depth-128 -fno-strict-aliasing -finline-functions -Wno-inline -Wall -pthread -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG  -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/gcc-4.5.1/gentoorelease/pch-off/threading-multi/acoshl.o" "libs/math/build/../src/tr1/acoshl.cpp"
libs/math/build/../src/tr1/acoshl.cpp:14:44: error: redefinition of 'long double acoshl(long double)'
/prefix/lib/gcc/powerpc-ibm-aix6.1.0.0/4.5.1/include-fixed/math.h:860:20: error: 'long double acoshl(long double)' previously defined here

This isn't bound to boost-1.44.0 or gcc-4.5.1, I do have this same problem with boost-1.45.0 (using gcc-4.5.1) as well as boost-1.39 (using gcc-4.2.4).

Thing is, AIX6.1 defines many math-functions as inlines in /usr/include/math.h already, as one can see in ​http://gcc.gnu.org/bugzilla/attachment.cgi?id=15004

[Noel Belcourt]

Hi,

I run some tests with vacpp-10.1 under Linux, not AIX, and most of the Math library is pretty good. A few failures here and there but mostly okay (see the Sandia-vacpp-10.1 trunk regression tester).

Is it possible that some / many of your problems are due to your limits being hosed?

xlC_r: 1501-245 (W) Warning: Hard ulimit has been reduced to less than RLIM_INFINITY. There may not be enough space to complete the compilation.

Can you un-limit you RLIM and see if that helps clears up some of the problems?

[Michael Haubenwallner <michael.haubenwallner@…>]

Nope, this doesn't have anything to do with limits. It even doesn't have to do so much with vacpp/xlc itself except that it is the reference-compiler on AIX. The problem has to do with /usr/include/math.h, which is completely different on AIX compared to Linux.

Since AIX 6.1, /usr/include/math.h defines math-functions as inlines, while they are in boost since ages.

The question simply is: Where is the (most) right place to declare/define these math functions: in boost, or in /usr/include/math.h?

Thank you!

[cpaolino@…]

As Michael said, I don't think the problem lies in limits, because I don't see any error like "Not enough space" from the compiler.

Also, we solved the problem with Python and zlibs. This is the compile script we are using now: ​https://gist.github.com/37e4e7d544e92e53489d

I will attach the new build log soon.

[cpaolino@…]

Failed build log (Boost 1.45). Compiled with the aforementioned script

[Michael Haubenwallner <michael.haubenwallner@…>]

Patch for boost-1.45.0 to avoid duplicate symbols both compile- and link-time on AIX 6.1

[Michael Haubenwallner <michael.haubenwallner@…>]

This patch allows for building boost without duplicate symbols on AIX 6.1 both compile- and link-time.

However, I don't think using '#ifdef _AIX61' is the right thing to do here.

But I don't have an idea where the /real/ problem is:

• in AIX6.1's <math.h> in that it should not define these symbols as inlines
  (so a proper fix should go to AIX6.1's math.h to drop them, we use #ifndef _AIX61 meanwhile), or
• in other platform's <math.h> in that they lack the (inline) definition of these symbols
  (so a proper fix should go to their math.h (and math-lib), we keep them in boost meanwhile), or
• in boost in that it should not define these symbols itself at all
  (so a proper fix should drop these definitions from boost code), or
• in boost in that it does not know that AIX6.1 defines these symbols
  (so using #ifndef _AIX61 is the proper fix), or
• others?

Thank you!

[Vladimir Prus]

This appears to be related to the Boost.Math library at present -- at least the patch I see is purely Boost.Math. Reassigning.

[anonymous]

I'll fix the Math lib issues by renaming the extern "C" functions, and providing the TR1 conforming names as forwarding functions (C++) or macros (C).

I'm testing this fix now, and will then close this issue.

IF THERE ARE ISSUES WITH OTHER LIBRARIES, PLEASE FILE SEPARATE ISSUES FOR THESE

Thanks, John.

[John Maddock]

(In [68653]) Change the name of the extern "C" TR1 functions so they no longer clash with (possibly inline) std lib versions. Fixes #4828.