On Fri, 22 Mar 2024 08:51:47 GMT, Andrew Haley <a...@openjdk.org> wrote:
>> @theRealAph Are you saying that bundling the source code of libsleef is a >> hard requirement from your side to accept this code into the JDK? >> >> I'm not against it, I just want to understand what we're talking about here. >> >> In general, adding new libraries to OpenJDK will require a legal process in >> Oracle, which may (or may not) take some amount of time T, where T is larger >> than you'd wish for. >> >> So I guess we can either: >> 1) wait for libsleef source code to become a part of OpenJDK, and then >> integrate this PR. >> 2) integrate this PR optimistically, and in the background start a process >> of trying to get libsleef into OpenJDK. (Which, of course, can not be 100% >> guaranteed to happen.) >> 3) integrate this PR as is, and give up any idea of bundling libsleef. >> >> I also believe there is a fourth option, but that too seems like it has >> legal implications that needs to be checked: >> >> 4) if the libsleef dynamic library is found on the system during build time, >> bundle a copy of the dll with the built JDK. (Similar to how was done with >> freetype on Windows before.). And, optionally, provide an option for >> configure to require libsleef to be present, so the build fails if no >> libsleef can be found and bundled. (Leaving open as to if this should be >> default or not.) > >> @magicus @theRealAph Thanks for discussion. >> > In the short term, I'd build a shim library during the default standard >> > JDK build that does not need SLEEF at build time. Unless weo do that, >> > because SLEEF isn't on anyone's builders, it won't be used. >> >> I agree it's give user more chance to leverage the sleef when running, but I >> wonder if it's necessary to do that. As we have a long term solution, and >> the chance that end user lacks sleef library in their environment is much >> higher than release engineer lacks sleef library in their environment. > > That situation leads to my nightmare, in which some OpenJDK builds work with > vector support, and some don't, and there's no way to find out which unless > you try it, in which case there is no warning, your programs just run slowly. > Even if you've installed SLEEF. That would be bad for our users, bad for > OpenJDK, and bad for Java. > >> But it's not harm to do so. @theRealAph An alternative to building libsleef is to *require* it as a build prerequisite on linux/aarch64. That way you will at least not end up in the situation you fear, where no build environment for the popular distributions have libsleef during build time, and in practice no end user will benefit either. Otoh, doing that will require us to send out the message for downstream builders to prepare, and waiting for them to prepare, and the question is if this is faster than bundling the source code... And if we're going the latter route anyway, then this approach will have been pointless. So, I guess, this is a worse solution. Just wanted to point out that it exists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2014795185
