Building on AIX

Tue Nov 13 08:41:20 PST 2012

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)".
>
>
>
>