building static libs for ios/android

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Wed Mar 27 13:04:27 UTC 2024


On 2024-03-25 18:43, Johan Vos wrote:

> Hi Magnus,
>
> Thanks for your reply. I can indeed tell that there are major changes 
> in upstream openjdk/jdk related to static builds, as the Skara ran 
> into 3 conflicts over the past week while merging from upstream :)
> That is great news, and I'm glad the static build gets traction in 
> openjdk/jdk.

Great! I look forward working with you to make sure we get a proper 
solution in upstream that will fit your needs as well.

> This might be a good moment to work on the remaining android/ios 
> specific clauses that are in openjdk/mobile but not (yet) in openjdk/jdk.

Unfortunately, that is a bit of a different story. :-( We tend to be 
very reluctant of accepting ports to new platforms, unless we have 
someone (basically, an organization or a company) backing up the port. 
That means things like providing a CI system for the platform, making 
sure there  is engineering resources available in case there is trouble 
with the platform in a future PR, committing to making the kind of 
changes necessary if the platform evolves (virtual threads is a great 
example of a highly complicated kind of change that might be needed), 
and finally, helping remove the platform if it falls out of grace.

I don't know if you and/or Gluon might be able to provide what would be 
needed. If you want to go down that route, we'd have to start a 
discussion on porters-dev and involve Dalibor.

There are at least two points in favor in this case, though:

1) The changes required are fairly minimal. ios is basically macosx, 
from the point of building, and android is basically linux. It's not 
like porting to RISC-V where the entire C2 needs to be rewritten.

2) I saw that you have already created tests on GitHub action for these 
ports. That means there is a simple way to make sure we keep the 
functionality tested, at least build-wise. (Someone will still need to 
run the tests on a regular basis, to make sure they don't break, though.)

/Magnus


> It is probably best to wait until you finished your current refactory 
> of the static builds approach. I'll make sure the openjdk/mobile 
> follows the new approach, so that the diff will be really small.
>
> I will probably merge my PR with the latest additional ios/Android 
> changes into mobile/HEAD as that will make it easier to merge the 
> incoming (openjdk/HEAD) changes with the latest changes for mobile.
>
> Thanks again,
>
> - Johan
>
> On Mon, Mar 25, 2024 at 3:31 PM Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com> wrote:
>
>     On 2024-03-23 17:42, Johan Vos wrote:
>
>     > Hi,
>     >
>     > I created a PR that brings in the remaining changes needed to
>     compile
>     > an image containing the static JDK libs (not the VM libs) for
>     ios/android:
>     > https://github.com/openjdk/mobile/pull/20
>     >
>     > As a major improvement, this PR also adds ios/android build scripts
>     > for GA (thanks to Abhinay Agarwal for doing this). As a
>     consequence,
>     > we will immediately notice if an upstream commit (in
>     openjdk/jdk) is
>     > breaking the build for the mobile static libs.
>     >
>     > In a previous message, I suggested a separate branch would be my
>     > preference for doing development work. However, there are 2 reasons
>     > why I prefer this PR to go into the main branch:
>     > 1. it seems I don't have permission to create new branches
>     > 2. there is at least 1 major embarrassing bug in the current main
>     > branch (fi instead of endif) hence an improvement sounds
>     appropriate.
>     >
>     > Slightly related: the auto-merge operation by the skara bot had 2
>     > merge conflicts recently, due to changes in the upstream make
>     > directories. I fixed the conflicts, and while I didn't look in the
>     > details yet, it seems Magnus is doing simplifications in
>     openjdk/jdk
>     > that are also simplifying some of the build logic for mobile.
>     That is
>     > great, thanks for that!
>
>     <ominous music>More change is on the horizon. A storm is
>     coming.</ominous music> Or maybe not. But things will happen in
>     the area
>     of static build. Hopefully good changes. :-) This is driven by the
>     Hermetic Java project, which requires static builds of the entire JDK.
>
>     I guess in the end this part of Hermetic Java is quite similar to the
>     mobile project, but with the intention of bringing this to
>     mainline. As
>     a result of this wish, I wanted to make sure that static build is
>     properly treated as a "first class citizen" in the build system.
>
>     I was under the impression that the mobile project was more or less
>     abandoned, but I'm happy to see this is not the case. I hope I can
>     communicate with you so that we end up creating a single solution for
>     producing static builds that are usable both for mobile and
>     Hermetic Java.
>
>     /Magnus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/mobile-dev/attachments/20240327/02e2d9be/attachment-0001.htm>


More information about the mobile-dev mailing list