Ubuntu 24.04 tools/jpackage failures
- Dominant language
- HTML
- Stars
- 155
- Forks
- 346
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 36
Description
Ref:
- https://github.com/adoptium/infrastructure/issues/3501#issuecomment-2160713162 (Confirmed on JDK17, but probably more widespread)
- https://fosstodon.org/@sxa/112439989472057061
As described in [the comment about the s390x](https://github.com/adoptium/infrastructure/issues/3501#issuecomment-2105675393) results, some of the `tools/jpackage` tests in jdk_tools (`jdk_tools_0` target in Grinder, or `make _jdk_tools_0` from the command line) in the extended.openjdk suite are failing on Ubuntu 24.04 because `dpkg -L libc6` now shows the package as being under `/usr/lib` instead of `/lib` on the new Ubuntu:
```
$ docker run ubuntu:22.04 dpkg -L libc6 | grep libc.so.6
/lib/aarch64-linux-gnu/libc.so.6
$ docker run ubuntu:24.04 dpkg -L libc6 | grep libc.so.6
/usr/lib/aarch64-linux-gnu/libc.so.6
```
(Noting that the there is a `/lib->/usr/lib` symlink in place, even on the earlier versions of Ubuntu, so they are still accessible in the expected location, so still ldd work). This seems to be what is preventing the location from `ldd` from being detected as part of the `libc6` package by the tests. The equivalent of what the tests are doing can be seen here on both distributions:
## Ubuntu 22.04
```
$ docker run -it ubuntu:22.04
root@a69c7509d0c4:/# ldd /bin/ls
linux-vdso.so.1 (0x0000ffff934bb000)
libselinux.so.1 => /lib/aarch64-linux-gnu/libselinux.so.1 (0x0000ffff93410000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff93260000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff93482000)
libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffff931c0000)
root@a69c7509d0c4:/# dpkg -S /lib/aarch64-linux-gnu/libc.so.6
libc6:arm64: /lib/aarch64-linux-gnu/libc.so.6
root@a69c7509d0c4:/#
```
## Ubuntu 24.04
```
$ docker run -it ubuntu:24.04
root@e77dadaee851:/# ldd /bin/ls
linux-vdso.so.1 (0x0000ffffab50a000)
libselinux.so.1 => /lib/aarch64-linux-gnu/libselinux.so.1 (0x0000ffffab440000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffab280000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffab4cd000)
libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffffab1d0000)
root@e77dadaee851:/# dpkg -S /lib/aarch64-linux-gnu/libc.so.6
dpkg-query: no path found matching pattern /lib/aarch64-linux-gnu/libc.so.6
root@e77dadaee851:/#
```
The output from `ldd` can be manipulated by setting `LD_LIBRARY_PATH=/usr/lib/aarch64-linux-gnu` so that is searched first (or equivalent path for your architecture) [*] but that doesn't feel like the right thing to do so this likely needs an upstream fix.
[*] - Note that setting the variable does NOT allow it to pass the tests when run through TKG on the command line.
Contributor guide
Assessment
This issue has not been assessed yet.