RFR: 8303796: Optionally build fully statically linked JDK image
Erik Joelsson
erikj at openjdk.org
Mon May 1 14:21:23 UTC 2023
On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>>> I pulled this PR and had a go at building it. For me it failed with errors like this:
>>>
>>> ```
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres'
>>> ```
>>>
>>> I haven't dug any deeper to try to figure this out. Is this something you recognize?
>>
>> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
>>
>>
>> /usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o /.../build/linux-x86_64-server-slowdebug/jdk/bin/javastatic /.../linux-x86_64-server-slowdebug/support/native/java.base/java/main.o -Wl,--whole-archive /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libattach.a ... /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
>>
>>
>> `clock_getres` and the other related symbols are provided by `libc`. For `libc`, we don't static link with. We still use `libc.so`.
>>
>>
>> $ ldd jdk/bin/javastatic
>> linux-vdso.so.1 (0x00007fff8b17a000)
>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0845321000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0845140000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f084888d000)
>>
>>
>>
>> $ objdump -Tw /lib/x86_64-linux-gnu/libc.so.6 | grep clock_getres
>> 00000000000cf260 g DF .text 0000000000000069 GLIBC_2.17 clock_getres
>> 00000000000cf260 g DF .text 0000000000000069 (GLIBC_2.2.5) clock_getres
>>
>> $ nm jdk/bin/javastatic | grep clock_gettime
>> U clock_gettime at GLIBC_2.17
>> $ nm jdk/bin/javastatic | grep clock_getres
>> U clock_getres at GLIBC_2.17
>
>> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
>
> I can't see any significant difference. I'm using a devkit created using the devkit makefiles.
>
>
> .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
> Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment?
Yes, it built cleanly with that change.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529742147
More information about the core-libs-dev
mailing list