Cleaning Up illumos and Solaris OS Support

[Toasterson]

As discussed on #1514 this Issue serves as the basis to coordinate and design the future, proper Solaris support.

First a small primer. Both Illumos and Oracle Solaris are forks of the Original Sun OpenSolaris. Thus all versions named Solaris 11.x and Illumos come from a common ancestor. They have however diverged drastically enough that they are no longer Binary compatible. With the new golang 1.13 for example a new platform has been added for illumos because of that.

As to the questions from @svaarala from #1514

Q: What Solaris versions and variants are relevant (not just the latest, but something that might be still in use in practice)? A: In illumos all distributions share a common upstream base repo named Illumos which is managed collaboratively by all distributions. A single Platform for Illumos is sufficient. For Oracle Solaris I think Solaris 11 and 10 are relevant still but it will be best if somebody more knowledgeable about this answers the Solaris side.

Q: What naming should be used for defines? A: Illumos, Solaris11 and Solaris10 for version specific differences. Illumos and Solaris for differences between the Projects. SunStudio support can be skipped entirely. Illumos only provides SunStudio for backwards compatibility for those projects that have not yet ditched support.

Q: What headers should be used, and can a single set of headers work? A: In this particular case sys/params.h is the matching headers. I have not checked if there are other cases yet.

I will ask around in the illumos irc if other people are willing to help you out with this. We have already good experiences with coordinating changes with the meson community.

Are there some projects that use your library that could be of interest for our community to run at home on their servers? That usually gives a nice boost in helpers for platform support. I know of gerbera from #1514 do you know any other software like that?

[alanc]

Solaris 10 is supported until 2024, Solaris 11 through 2034 (but only the latest 11.x release, currently 11.4 - not older releases like 11.0 or 11.2).

It's been a few years since I tried, but I don't remember much problem building duktape on Solaris 11 - is there something specific needed beyond the fix from #1514?

[ghost]

(I'm following up as this link was posted on IRC.)

Solaris (whatever version) and illumos (all lowercase) should be handled separately as while illumos is OpenSolaris fork, there's no guarantee the choices we do for illumos will be the same done in Solaris.

Other than that, if there's something missing in illumos-gate that is required for duktape to build/run on illumos, please create a bug report in https://www.illumos.org/projects/illumos-gate/issues.

[svaarala]

Thanks guys, I hope once this clears up we can have clear detection for all necessary variants. What's important for that is finding C preprocessor defines that are available before any headers are included. So hopefully one can reliably distinguish whatever variants are necessary that way.

[svaarala]

I'll install OpenIndiana and see what defines are available. It seems the best first step is to add illumos detection, and then ensure the existing Solaris detection works for versions prior to that.

[alanc]

All the distros derived from SunOS (Solaris, OpenIndiana, OmniOS, Tribblix, etc.) should have __sun defined by the C & C++ compilers. I don't remember if there's any #define to distinguish between Oracle Solaris and the illumos family though.

[svaarala]

I now have an OpenIndiana VM, using gcc 6.5.0 (OpenIndiana 6.5.0-oi-2). I looked at the output of gcc -dM -E - < /dev/null | sort and at a glance it seems there is nothing to distinguish illumos specifically:

• __sun 1
• __sun__ 1
• __SVR4 1
• __svr4__ 1
• __unix 1
• __unix__ 1
• sun 1
• unix 1

Others seem pretty generic.

Is there some header that could be included (contingent on the shared Solaris defines and available in illumos and other variants too) that would provide some version / variant defines that could distinguish the platforms? Grepping around /usr/include I didn't find an obvious candidate:

• Some internal headers check for _ILLUMOS_PRIVATE, not sure what defines it, and by its name it seems unsuitable.
• sys/sysevent.h provides ILLUMOS_VENDOR "ILLUMOS" and a define ILLUMOS_KERN_PUB. Maybe the former might be workable if sys/sysevent.h is always safe to include.
• Sidenote: some headers seem to check for __solaris__ and __SOLARIS__ which is not in the predefines list, these are probably for earlier versions.

Ultimately it would be possible to just require the application writer define something. There's one case of that in duk_config.h IIRC, but it's obviously very undesirable compared to automatic detection.

At present, assuming ast/endian.h is not required for byte order on any practical Solaris variant, the distinction between these variants is not necessary. But as pointed above, at some point it may be.

[svaarala]

@Toasterson Regarding this comment https://github.com/svaarala/duktape/pull/1514#issuecomment-533431807:

I'm not sure I understand what you meant by:

The fact that it detects current Solaris and Illumos Systems as "Old" is definitely wrong.

So to clarify:

In master there is a "Solaris" platform detected based on DUK_F_SUN which in essence means __sun && __SVR4. Anything with these these gets the platform name "solaris" at present (and we'd like illumos based systems to distinguished, but that's a separate thing).

Within that detection, there is a hack for "old Solaris" without endian.h or stdint.h, detected by presence of __SUNPRO_C, and it gets some byteorder forcing etc. This should not match for at least illumos (based on a gcc predefs dump).

So, it's not the case that all Solaris variants detect as "old Solaris", they appear outward as "solaris".

Where this old Solaris hack came from I'm not fully sure, but probably someone working on these old Solaris targets has provided it or requested it (yes, some people work on way out of date platforms for various reasons :).

[Toasterson]

@svaarala I thought ast/endian.h got included because illumos was detected as old solaris. But I think that is more me not being fluent in C Preprocessor macros as it turns out. Thank you for clarifying.

[alanc]

__SUNPRO_C does not indicate a version of Solaris, but the use of the Sun/Oracle Studio compilers instead of gcc or clang.

<stdint.h> has been present on Solaris since the Solaris 10 release in 2005, so a version without it is truly old now. The ast headers are really from ksh93, not the core Solaris/illumos OS.

[svaarala]

__SUNPRO_C does not indicate a version of Solaris, but the use of the Sun/Oracle Studio compilers instead of gcc or clang.

I think it was used as a proxy to detect older versions (but I don't really know the exact intention), but I don't know if it is really appropriate.

[Toasterson]

Well it can work as a proxy due to the fact that Sun/Oracle Studio compilers are the only compilers present on older Solaris versions. But they could be also present on current illumos and Solaris boxes iirc. So it's a dirty hack at best.

[svaarala]

Agreed.