That is a good question. libiconv is used only on macOS and AIX, for a
few libraries, as you say. I just tried removing -liconv from the macOS
dependencies and recompiled, just to see what would happen. There were
three instances for macOS: libsplashscreen, libjdwp and libinstrument.
Out of these, libinstrument compiled and linked fine without the -liconv
argument. It looks like iconv is referenced in
unix/.../EncodingSupport_md.c, but otoh it looks like it is as much (or
as little) referenced on macOS as on linux (where we never have linked
with -liconv) so it is perhaps just dead code. I did not study it in
detail. The code looks very much duplicated from libjdwp.
The other two actually failed linking, so they do use libiconv.
libsplashscreen uses it in splashscreen_sys.m, where it is used to
convert the jar file name.
libjdwp uses it in utf_util.c, where it is used to convert file name and
command lines, iiuc.
It is likely that we have similar (but better) ways to convert charsets
elsewhere in our libraries that can be used instead of libiconv. I guess
these are not the only two places where a filename must be converted
from the platform charset to UTF8.
/Magnus
On 2024-04-23 14:11, Bernd Eckenfels wrote:
Du to a glibc security alert about a charset in iconv() I checked OpenJDK
(since I was quite sure encoding is handled in JCL), however there are a few
utilities (related to libinstrument and splash Screens) which use iconv.
If I see it correctly it’s mostly used for utf8 so it should not expose this
particular globe weakness, but I still wonder if that dependency is needed. For
some platforms like AIX it even drags on an additional library dependency. (Not
to mention different charger tables and especially ugly locale dependencies for
containers).
Gruß
Bernd
—
https://bernd.eckenfels.net
