Building on non-std architectures
david.holmes at oracle.com
Tue Sep 30 18:06:11 UTC 2014
On 1/10/2014 4:03 AM, pointo1d wrote:
> Hiya Dave ,
> On 30/09/14 18:57, David Holmes wrote:
>> Hi Dave,
>> On 1/10/2014 2:05 AM, pointo1d wrote:
>> For general cross-compilation we just set extra-cflags to pass things
>> like this through; and don't set the --with-target-bits option.
>> Aside: I would think that supporting 31-bit would require a huge
>> number of changes to the sources (unless it is somehow masked by the
>> C/C++ compiler.
>> David H.
>>> TIA & rgds ,
> TFT fast response Dave.
> I did play with that, but having invoked configure as ...
> --with-extra-cflags="-m31 -DIBM_DBGMALLOC
> -I/home/foreman/sandbox/thirdparty/include -I/usr/include/freetype2"
> --with-extra-ldflags="-m31 -L/usr/X11R6/lib"
> --with-extra-cxxflags="-m31" --openjdk-target=s390-linux
> --with-boot-jdk-jvmargs=-Xmx800m --x-libraries=/usr/X11R6/lib
> I always encounter the configure error ...
> checking size of int *... 8
> configure: The tested number of bits in the target (64) differs from the
> number of bits expected to be found in the target (31).
> configure: I'll retry after setting the platforms compiler target bits
> flag to -m31
> checking size of int *... 4
> configure: error: The tested number of bits in the target (32) differs
> from the number of bits expected to be found in the target (31)
> configure exiting with result code 1
Okay that sounds like we need a major change in the configure logic. Can
you tell if this comes from our specific .m4 processing or is this part
of configure's inbuilt checking?
This will be my last quick response :) At JavaOne.
More information about the build-dev