"useless" librt.so.1 dependency on Linux reported by dpkg-shlibdeps

[Thomas Stüfe]

Hi,

AFAICS glibc 2.17 (or later) are supported in:

- RHEL 7.9 and later
- Oracle 7.9 and later (direct RHEL spinoff, same versioning)
- SLES 12 SP5 and later
- Debian: Jessie (Debian 8) and anything later. Jessie not supported
anymore. Current oldoldstable is Bullseye (Debian 11).
- Raspbian: any version after 2017, basically.
- Ubuntu: 14.04 and anything later. 14.04 is the last version Canonical
still sells support for, AFAIK.

Noteworthy still supported commercial Linuxes with older glibcs: AFAICS
only RHEL 6.9. We (IBM, Redhat) don't care about JDK 26 on these old
systems.

Cheers, Thomas



On Fri, Sep 19, 2025 at 2:39 PM David Holmes <david.holmes at oracle.com>
wrote:

> On 19/09/2025 10:21 pm, Baesken, Matthias wrote:
> > Hi David,  even  on RHEL   7.9   it works without  adding  -lrt to
> linking , see the example   :
>
> It is only pre glibc 2.17 that we need librt.so for.
>
> David
>
> >
> > gcc --version
> > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is
> NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> >
> > gcc clock_gettime.c -o clock_gettime
> > ./clock_gettime
> > Elapsed time: 2.008803 seconds
> >
> > more ./clock_gettime.c
> > #include <stdio.h>
> > #include <time.h>
> > #include <unistd.h>
> >
> > int main() {
> >      struct timespec start, end;
> >      double elapsed;
> >
> >      // Get start time
> >      clock_gettime(CLOCK_MONOTONIC, &start);
> >
> >      // Simulate some work (sleep for 2 seconds)
> >      sleep(2);
> >
> >      // Get end time
> >      clock_gettime(CLOCK_MONOTONIC, &end);
> >
> >      // Calculate elapsed time in seconds (as a double)
> >      elapsed = (end.tv_sec - start.tv_sec);
> >      elapsed += (end.tv_nsec - start.tv_nsec) / 1e9;
> >
> >      printf("Elapsed time: %.6f seconds\n", elapsed);
> >
> >      return 0;
> > }
> >
> >
> > ldd --version
> > ldd (GNU libc) 2.17
> >
> >
> >
> > But  on ancient   SLES 11  (SUSE Linux 11)  with
> > ldd --version
> > ldd (GNU libc) 2.11.3
> >
> >
> > I see the issue  ,  there I have to add   -lrt  :
> >
> > gcc  clock_gettime.c  -o   clock_gettime
> > /tmp/ccU07fSz.o: In function `main':
> > clock_gettime.c:(.text+0x20): undefined reference to `clock_gettime'
> > clock_gettime.c:(.text+0x40): undefined reference to `clock_gettime'
> > collect2: ld returned 1 exit status
> >
> >
> > gcc  clock_gettime.c  -o   clock_gettime -lrt
> > ./clock_gettime
> > Elapsed time: 2.000108 seconds
> >
> >
> > So it seems we have to go back to SLES11   and RHEL 6  (!)   for this
> strange  librt  issue .
> >
> > Best regards, Matthias
> >
> >
> >
> > -----Original Message-----
> > From: Baesken, Matthias
> > Sent: Friday, 19 September 2025 09:42
> > To: 'David Holmes' <david.holmes at oracle.com>; build-dev at openjdk.org;
> hotspot-dev <hotspot-dev-retn at openjdk.org>
> > Cc: Langer, Christoph <christoph.langer at sap.com>
> > Subject: RE: "useless" librt.so.1 dependency on Linux reported by
> dpkg-shlibdeps
> >
> > Hi David, I found a RHEL  7.9   machine with an old glibc  :
> >
> > ldd --version
> > ldd (GNU libc) 2.17
> >
> > But the gcc on this machine  is 4.8.5  , probably too  old   to build
> OpenJDK there to see  if this change breaks something .
> >
> > Any idea what I should test  on this old machine  regarding librt.so.1
>  ?
> >
> >
> > Best regards, Matthias
> >
> >
> >
> >>>>>
> >>>>> ( seems some versions of  RHEL 7  / SLES 12  still had those old
> glibc
> >>>>> versions)
> >>>>>
> >>>>> Could we clean this up?
> >>>>>
> >>>>> Or is there still some need  to  support this in jdk26  ?
> >>>>
> >>>> I always find it very difficult to determine when checks like these
> >>>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
> >>>> release we currently support.
> >>>>
> >>>> Given I wrote the above in April 2021, I would hope we can now move
> on,
> >>>> but again I don't know how to readily determine that.
> >>>
> >>>
> >>> I could create a removal PR and maybe you can test on the oldest
> platforms you want to support in release 26 ?
> >>
> >> I don't have access to such systems for testing.
> >>
> >> David
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250919/9cebd0ec/attachment.htm>