On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson <er...@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@GLIBC_2.17 >> $ nm jdk/bin/javastatic | grep clock_getres >> U clock_getres@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
