Looks good!
Thanks for your patience and perseverance! :)
David
On 5/10/2018 7:18 AM, Kim Barrett wrote:
On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>
wrote:
That all assumes that static build actually works at all; it doesn’t look like
we
test that configuration these days, so who knows what bit rot may have set in.
No, we don't test static build, and never have. I'd be surprised if it's still
possible to build a static build.
This was a feature developed for the mobile project. The static build part was
merged, somewhat hastily, into mainline, but the rest of the mobile code is
still lingering in the mobile project fork.
The entire "static build" concept was somewhat artificially injected in some
parts of the build code. It is for instance not possible to build all modules with a
static build. At the very least you need to build without java.desktop, if I remember
correctly.
The motivation for the static build is that on iOS, apps are not allowed to
load dynamic libraries (for some reason only Apple knows). So a developer that
wants to build a Java app needs to have a static library version of the entire
JDK to link with into a single executable Java launcher. So in this
perspective, the entire use of dlopen in a static build smells funny, and might
be just a left-over from static build being more of a hack than a properly
supported build option.
/Magnus
The "static build" doesn't build anymore. We're all shocked that this
untested configuration has bit-rotted. :)
LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the
workaround is superfluous in that case. Given that, I'm going to
delete the workaround and file an RFE [1] to fix or remove the
currently broken "static build" support, with a comment there
referring to this workaround code as possibly being relevant to fixing
the static build.
[1] https://bugs.openjdk.java.net/browse/JDK-8211732
New webrev:
http://cr.openjdk.java.net/~kbarrett/8211296/open.01/
