Boost C++ Libraries: Ticket #4828: Boost fails to compile on AIX 6.1 with IBM XL C/C++ V10.01

attachment set

cpaolino@… — Tue, 09 Nov 2010 15:50:13 GMT

attachment → boost_fail.log

Failed build log

Fri, 26 Nov 2010 15:49:51 GMT

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 — Sat, 27 Nov 2010 02:53:06 GMT

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?

Mon, 29 Nov 2010 08:46:09 GMT

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@… — Mon, 29 Nov 2010 09:00:51 GMT

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.

attachment set

cpaolino@… — Mon, 29 Nov 2010 09:04:23 GMT

attachment → boost_fail.2.log

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

attachment set

Mon, 13 Dec 2010 13:49:13 GMT

attachment → boost-1.45.0-aix61-math.patch

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

Mon, 13 Dec 2010 14:22:39 GMT

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!

component changed; owner set

Vladimir Prus — Tue, 01 Feb 2011 09:33:54 GMT

owner set to John Maddock
component Building Boost → math

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

anonymous — Fri, 04 Feb 2011 12:15:19 GMT

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.

status changed; resolution set

John Maddock — Sat, 05 Feb 2011 10:49:59 GMT

status new → closed
resolution → fixed

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