Latest repo fails to build on OS X
Kelly.Ohair at Sun.COM
Mon Dec 1 11:23:44 PST 2008
I don't think anyone can assume that intptr_t will be defined to int32_t or int64_t,
it's only requirement is to be able to hold a pointer.
Seems like a nasty problem, and if the OpenJDK sources are depending on intptr_t
being the same type as int32_t or int64_t,
I have to agree that it should be treated as an OpenJDK bug.
I think this should go to the hotspot-dev at openjdk.java.net alias, make sure
you include the trace:
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: In member function
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: error: call of
overloaded 'movptr(Address, int)' is ambiguous
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: note: candidates
are: void MacroAssembler::movptr(Address, intptr_t)
void MacroAssembler::movptr(Address, RegisterImpl*)
make: *** [incls/_precompiled.incl.gch] Error 1
make: *** [the_vm] Error 2
make: *** [product] Error 2
make: *** [generic_build2] Error 2
make: *** [product] Error 2
make: *** [hotspot-build] Error 2
make: *** [build_product_image] Error 2
Greg Lewis wrote:
> On Sun, Nov 30, 2008 at 08:30:06AM -0500, Michael Franz wrote:
>>> All we have since then are merges from the main OpenJDK repository.
>>> In reference to your follow ups, I can build the code on both FreeBSD/i386
>>> and FreeBSD/amd64, so that covers both 32 bit and 64 bit platforms.
>>> I also see from your followups that Mac OS X is 32 bit, so this code will
>>> end up being
>>> movl(dst, src);
>>> no matter which variant the compiler picks. It should pick the intptr_t
>>> version though. In fact, on FreeBSD/i386 intptr_t is typedef'ed to
>>> int32_t, so these are the same.
>>> I wonder how intptr_t is defined on Mac OS X and what version of gcc is
>>> being used? You could try changing the cast to (intptr_t) instead of
>>> (int32_t), since it should basically be the same.
>> Based on what is in <stdint.h> int32_t is a signed int and intptr_t is an
>> signed long. Apple is using gcc 4.0.1.
>> For the original issue I did change the cast from int32_t to intptr_t and it
>> works, however, there are other issues that follow that related to the same
>> change. I could go through and change all the places it breaks, but there
>> must be and easier fix.
> I agree. The root problem appears to be the assumption that on 32 bit
> platforms intptr_t and int32_t are typedef'ed to the same thing. This
> is clearly not the case on Mac OS X. This is something I'd like to take
> up on the main OpenJDK list since its not BSD specific (it just happens
> that it only breaks on one of our supported OSes).
> I'll try and find time to send out an email tonight.
More information about the bsd-port-dev