Building on AIX

[Steve Poole]

Build times for my 100% clean build



#-- Build times ----------
Target debug_build
Start 2012-11-13 17:32:23
End   2012-11-13 19:07:42
00:13:05 corba
00:04:07 hotspot
00:05:08 jaxp
00:06:22 jaxws
01:01:54 jdk
00:04:43 langtools
01:35:19 TOTAL




On 13 Nov 2012, at 17:08, Steve Poole <spoole at linux.vnet.ibm.com> wrote:

> My builds are somewhat bogus as I didn't do a complete build in one pass.   I have one cooking now.  We'll see what it says later.
> I am using your bootstrap build not j9.
> 
> 
> 
> On 13 Nov 2012, at 16:41, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
>> Hi Steve,
>> 
>> what a great success!!! Congratulations:)
>> 
>> From your build times I suppose you used the J9 as bootstrap JDK,
>> right?  (or you must be on a really REALLY fast box).
>> 
>> Regarding 'xlc', I think the build only expects to find it in the PATH
>> which was always the case on our machines. One of my colleagues just
>> told me that "officially released" versions create these links by
>> default while this has to be done manually for "internal versions".
>> 
>> Regards,
>> Volker
>> 
>> On Tue, Nov 13, 2012 at 4:05 PM, Steve Poole <spoole at linux.vnet.ibm.com> wrote:
>>> 
>>> And the answer is :
>>> 
>>> #-- Build times ----------
>>> Target debug_build
>>> Start 2012-11-13 14:20:19
>>> End   2012-11-13 14:57:17
>>> 00:00:23 corba
>>> 00:00:09 hotspot
>>> 00:00:44 jaxp
>>> 00:01:43 jaxws
>>> 00:33:15 jdk
>>> 00:00:44 langtools
>>> 00:36:58 TOTAL
>>> 
>>> 
>>> 
>>> it builds for me with  AIX 7.1 and XLC 10
>>> 
>>> However I had to create links in /usr/bin   for xlc_r and xlC_r   back to
>>> the vac directories     I didnt investigate if this was my problem or a
>>> generic one.  I do know that the links are not created automatically  so
>>> either my paths were wrong or the build has a expectation for the location
>>> of the compilers.
>>> 
>>> 
>>> 
>>> On 13 Nov 2012, at 08:53, Steve Poole <spoole at linux.vnet.ibm.com> wrote:
>>> 
>>> 
>>> On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> 
>>> Yes, and what I forgot to say:
>>> 
>>> Steve, could you please, please try with XLC 10 just to verify that
>>> besides all these C++ compiler bugs, the general build is working and
>>> is producing reasonable results.
>>> I think this is really  very important such that we can finally get
>>> started with the work on the class library (for JDK 7 and 8).
>>> 
>>> Yes will do and will take your excellent testcase to the compiler guys.
>>> 
>>> Thank you and best regards,
>>> Volker
>>> 
>>> On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>> 
>>> Hi Steve,
>>> 
>>> sorry to say it, but I'm pretty sure this is yet another XLC bug and
>>> one of the reasons why we are still tied to XLC 10 (which is a
>>> shame!).
>>> I could reproduce the error with a version of XLC 12:
>>> 
>>> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
>>> Version: 12.01.0000.0000
>>> 
>>> Unfortunately the 12 compiler is just on a test system where I can't
>>> compile the whole JDK. But I could narrow the problem down to the
>>> following little, self contained C++ program (based on the original
>>> HotSpot sources):
>>> 
>>> /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
>>> class FOO {
>>> public:
>>> ~FOO() {}
>>> };
>>> 
>>> class StackObj {
>>> public:
>>> void  operator delete(void* p) {}
>>> };
>>> 
>>> class MethodHandleWalker : StackObj {
>>> FOO foo;
>>> };
>>> 
>>> class MethodHandleCompiler : public MethodHandleWalker {
>>> };
>>> 
>>> int main(int argc, char* argv[]) {
>>> 
>>> {
>>> MethodHandleCompiler mh;
>>> }
>>> 
>>> return 1;
>>> }
>>> /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
>>> 
>>> If compiled with XLC 12, it provokes the very same error message:
>>> 
>>> xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp
>>> 
>>> "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198
>>> (W) The omitted keyword "private" is assumed for base class
>>> "StackObj".
>>> "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S)
>>> The "private" member "class StackObj" cannot be accessed.
>>> "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I)
>>> The previous message was produced while processing the implicit member
>>> function "MethodHandleCompiler::~MethodHandleCompiler()".
>>> "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I)
>>> The previous message was produced while processing "main(int, char
>>> *[])".
>>> 
>>> This code works with all other compilers we know (at least  XLC 10,
>>> GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that
>>> XLC 12 is wrong.
>>> The problem is that XLC claims that the "StackObj" class is not
>>> accessible from within the synthetically generated destructor of the
>>> class "MethodHandleCompiler". That is true, because "StackObj" is a
>>> private base class "MethodHandleWalker" from which
>>> "MethodHandleCompiler" inherits.
>>> 
>>> But that's not the point here! The synthetically generated destructor
>>> of the class "MethodHandleCompiler" (i.e.
>>> "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct
>>> the members of "MethodHandleCompiler" and call the destructor of its
>>> base classes. And in turn, the synthetically generated destructor of
>>> its base class "MethodHandleWalker" could access its base class
>>> "StackObj" very well!
>>> 
>>> We would be really deeply grateful if you could escalate this bug to
>>> your internal XLC compiler group colleagues. After all, the HotSpot
>>> code is more than 10 years old C++ code which doesn't  use neither
>>> Exception Handling nor RTTI and only some very simple template
>>> constructs and I think this code should be correctly compilable by
>>> every reasonably decent C++ compiler nowadays.
>>> 
>>> After all, your XLC team can freely access and build the OpenJDK
>>> sources so it should be not too hard for them to reproduce this and
>>> maybe other problems.
>>> 
>>> Regards,
>>> Volker
>>> 
>>> 
>>> On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole at linux.vnet.ibm.com>
>>> wrote:
>>> 
>>> hi guys.   The build instructions from Volker seem to work ok on my AIX
>>> machine up to a point.
>>> 
>>> Using V11 of the XLC compiler I hit a compiler bug.   When I move to the
>>> latest V12 version I get this below in the build log..
>>> 
>>> Seems to be a pretty hard failure -  any advice?
>>> 
>>> Cheers Steve
>>> 
>>> 
>>> Compiling
>>> /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp
>>> rm -f ciObject.o
>>> xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm
>>> -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated
>>> -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\""
>>> -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\"
>>> -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc
>>> -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc
>>> -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti
>>> -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla
>>> -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090
>>> -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE      -c -qmakedep=gcc
>>> -MF ../generated/dependencies/ciObject.o.d -o ciObject.o
>>> /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp
>>> "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp",
>>> line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be
>>> accessed.
>>> "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp",
>>> line 272.7: 1540-0719 (I) The previous message was produced while processing
>>> the implicit member function
>>> "MethodHandleCompiler::~MethodHandleCompiler()".
>>> "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp",
>>> line 69.3: 1540-0700 (I) The previous message was produced while processing
>>> "ciMethodHandle::get_adapter_impl(bool)".
>>> 
>>> 
>>> 
>>> 
>> 
>