illumos port

[Greg Lewis]

On 2020-01-17 00:31, Magnus Ihse Bursie wrote:
> On 2019-12-04 20:22, Peter Tribble wrote:
>> Background
>> ==========
>>
>> The illumos project is a continuation of the OpenSolaris project. It
>> has an active community, has a number of distributions, and a number
>> of commercial companies use it as the basis for their products.
>>
>> Currently, illumos uses the Solaris port of OpenJDK, which mostly
>> works because Solaris and illumos share a common heritage.
>>
>> The recent JEP 362 (https://openjdk.java.net/jeps/362) impacts
>> illumos, as OpenJDK currently classes us as a Solaris port.
>>
>> Proposal
>> ========
>>
>> Prompted by JEP 362, I would like to suggest the creation of an
>> OpenJDK illumos porting project, distinct from the Solaris port.
>>
>> This port differs from the existing Solaris port in that it would use
>> gcc, rather than the Studio compilers. This should make illumos much
>> closer to the Linux and BSD ports. The work to use gcc (or to dissuade
>> the build from wanting Studio) has already been done, and most illumos
>> distributions (and pkgsrc) build their OpenJDK packages with gcc today.
>>
>> This port will only address the x64 architecture, as that is the
>> primary architecture supported by the illumos project.
>>
>> This port would (largely) inherit the Solaris-specific source already
>> in OpenJDK, modified as necessary for gcc.
>>
>> Separating illumos from Solaris also has a precedent in the Go project,
>> where the recent Go 1.13 release recognized illumos as a separate (but
>> related) platform.
>>
>> At the present time I'll be the contact person; a number of
>> individuals and organization within the illumos community have offered
>> support. If the Porters Group supports this proposal then we can put
>> together a list of people with appropriate roles.
>
> From a build perspective, supporting something that closely resembles
> Solaris, but only on x64, and with gcc, does not sound like an
> overwhelming task (in stark contrast to e.g. continuing support of sparc).
>
> There's likely several gotchas on the way to getting this working,
> though. I've made experimental attempts from time to time to use gcc
> on solaris, and that indicated that quite some work is needed to get
> this to work. For one thing, all current solaris-only files presuppose
> solstudio as the compiler. The second biggest thing is the problem
> that since we've traditionally had a more or less one-to-one mapping
> between compilers and OSes, we have sometimes been sloppy to
> distinguish between if we're really testing for solaris, or for
> solstudio (and sometimes it's even hard to tell which one it is you
> *should* use, even if you try to be correct).


FWIW, the BSD port has for a long time supported compiling with either
gcc or clang.  Granted they are probably closer to each other than gcc
and solstudio, but there are examples of how to support multiple
compilers per OS.  When we updated for openjdk11 I was actually
pleasantly surprised in terms of the extent of support for both gcc and
clang in the base code.


-- Greg


>
> But given an initial port to solaris-x86+gcc, I think the continuous
> burden of support you'll be undertaking is not too hard. In earnest, I
> think JEP 362 should have better been named "Deprecate Solaris Studio
> and SPARC", because that's what causing us trouble to keep supporting.
>
> /Magnus
>
>>
>> Note
>> ====
>>
>> If others wish to see Solaris support within OpenJDK continue, we're
>> happy to work with that. It still makes sense to regard Solaris and
>> illumos as different platforms, as both the platform and toolchain
>> have diverged from their shared ancestry.
>>
>> Likewise, illumos still supports the SPARC architecture. If SPARC
>> support was retained for other operating systems, we would be happy to
>> collaborate on that. Supporting SPARC is not something we could do on
>> our own, though, and it wouldn't be a primary focus for us.
>>
>> Thanks!
>>
>> -- 
>> -Peter Tribble
>> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/porters-dev/attachments/20200117/79c6c805/attachment.htm>