Link error building jdk9/jdk9

[Simon Nash]

On 22/12/2016 14:58, Bob Vandette wrote:
> I tried cross compiling with 2 different 4.7.2 GCC versions and had issues with the older one but it appears you
> are running an even newer version than I am.
> 
> Works
> 
> gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux
> gcc version 4.7.2 20120910 (prerelease) (crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09)
> 
> Fails
> 
> gcc-linaro-arm-linux-gnueabihf-2012.07-20120720_linux
> gcc version 4.7.2 20120701 (prerelease) (crosstool-NG linaro-1.13.1-2012.07-20120720 - Linaro GCC 2012.07)
> 
> Here’s my failure when I use the 2012.07 version:
> 
> /java/embedded/buildtools/gcc/linux/arm/gcc-linaro-arm-linux-gnueabihf-2012.07-20120720_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.2/../../../../arm-linux-gnueabihf/bin/ld: /java/embedded/buildtools/gcc/linux/arm/gcc-linaro-arm-linux-gnueabihf-2012.07-20120720_linux/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libm.a(mpa.o): relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> /java/embedded/buildtools/gcc/linux/arm/gcc-linaro-arm-linux-gnueabihf-2012.07-20120720_linux/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libm.a: could not read symbols: Bad value
> collect2: error: ld returned 1 exit status
> make[3]: *** [/export/users/bobv/jdk9dev-open/build/b00/linux-arm/support/modules_libs/java.base/server/libjvm.so] Error 1
> 
> Bob.
>
Thanks for this.  The cross-compiler part is working OK for me.  It is the buildjdk
part with the system toolchain that is failing.  It was not failing with jdk9-arm3264,
so I presume there is some difference between that and jdk9/jdk9.

Your link command is at least producing error messages.  It is the absence of any
messages for my link error that is puzzling me.

I will try again with jdk9-arm3264 to confirm whether this is still working with
my setup.  It would not be easy for me to update my system toolchain to a later
level, so I would prefer to make this work with 4.8.4 if possible.

Simon

> 
>> On Dec 21, 2016, at 6:22 PM, Simon Nash <simon at cjnash.com> wrote:
>>
>> I am trying to build jdk9/jdk9 using the configuration that I have been using to
>> build jdk9-arm3264.  Here is my configure command:
>>
>> bash ./configure --with-jdk-variant=normal --with-jvm-variants=server --with-abi-profile=arm-vfp-hflt --with-conf-name=hardfp \
>> --with-debug-level=release --disable-warnings-as-errors --openjdk-target=arm-linux-gnueabihf \
>> --with-tools-dir=/sd1/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin \
>> --with-sys-root=/sd1/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/arm-linux-gnueabihf/libc \
>> --with-cups=/sd1/armhf/cups --with-freetype=/sd1/armhf/freetype2 --with-alsa=/sd1/armhf/alsa \
>> --x-includes=/sd1/armhf/X11/include --x-libraries=/sd1/armhf/X11/lib --disable-freetype-bundling --with-boot-jdk=/sd1/java/jdk1.8.0_25 \
>> CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++ CPP=arm-linux-gnueabihf-cpp CXXCPP=arm-linux-gnueabihf-cpp \
>> LIBS="-Wl,-rpath-link /sd1/armhf/freetype2/lib -Wl,-rpath-link /sd1/armhf/X11/lib"
>>
>> The cross-compile has worked OK but there is a a link error building the native libjvm.so
>> in buildjdk with no error message to say what is wrong.  Here is the link command and the
>> output I am getting:
>>
>> nash at angels:/sd1/jdk9$ /usr/bin/g++ -Wl,-V -Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 -Wl,-z,relro -static-libstdc++ -static-libgcc -shared -Wl,-version-script=/sd1/jdk9/build/hardfp/buildjdk/hotspot/variant-server/libjvm/mapfile -Wl,-soname=libjvm.so -o /sd1/jdk9/build/hardfp/buildjdk/support/modules_libs/java.base/server/libjvm.so @/sd1/jdk9/build/hardfp/buildjdk/hotspot/variant-server/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt -lm -ldl -lpthread
>> collect2: error: ld returned 1 exit status
>>
>> Here is my native g++ version:
>>
>> nash at angels:/sd1/jdk9$ g++ --version
>> g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
>>
>> Could there be some incompatibility or bug in this fairly old level of g++?
>>
>> Simon
> 
>