Notices by Peter Tribble (ptribble@mastodon.social)

What are the chances of being able to build software from Oracle (openjdk) on an Operating system from Oracle (Solaris 11.4) with a compiler from Oracle (Developer Studio 12.4 and 12.6)?

If you guessed "essentially zero", you're pretty close 😞

Having got openjdk building with clang on illumos, running the test suite is as clean as a gcc build, which is really rather good.

Maybe I could declutter Tribblix by removing things that fail to give me joy.

Hmmmmmm.

First on the chopping block would be glib2, which has failed to give me any joy for the past couple of days. Removing it would render the bug I'm chasing moot, but only by removing all the packages in Tribblix that depend on it.

I keep asking myself "interesting" questions. Like, can I get KDE running on Tribblix.

Most of KF6 builds without too much difficulty. But there's a lot of it, I've got 35 packages so far, and eventually I need something to test that it's not a total failure.

Well, kmines works, so that's a start.

I've written up some notes on how to install Tribblix to UFS on UEFI

https://ptribble.blogspot.com/2025/03/tribblix-uefi-and-ufs.html

In doing this, I learnt how the EFI system partition (ESP) and boot partition actually work, which is always a good outcome.

(And spent more time in the EFI shell scratching my head than I would have planned.)

On #illumos the UFS file system isn't long for this world. It won't survive Y2038, for starters.

But you can still install the latest #Tribblix to UFS root, on a UEFI system no less. It's a bit tricky, and has some complex manual steps to get there. I'm not sure if making it easier is a good idea, as UFS isn't really something we want to encourage.

jack@tribblix:~$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/dsk/c1t0d0s0 7.4G 664M 6.7G 9% /

I have a handful of old machines I use for Tribblix testing. One of them was originally installed with Tribblix m8 (that's a long long time ago) and has been upgraded through every release since. (That's about 40 upgrades, I reckon.)

Something was bound to break eventually. In the recent past, it managed to lose the eventfd and timerfd devices. Which would have gone unnoticed, but getaddrinfo() stopped working, which broke curl, which broke the next upgrade as it couldn't download anything.

I've put together some pages on the state of illumos on SPARC

http://www.tribblix.org/sparc/

For reasons, I currently have a Netflix free trial. One of the things it asks you to do at signup is to select 3 shows you like. It was a sorry selection I was offered, so pick 3 at random. Once in, I really can't see anything I actually want to watch, so the trial is unlikely to lead to me signing up for good. Or even watching it at all in the trial period.

(It's not just Netflix; there's very little current TV that I have any interest in. It's a barren wasteland.)

One of the plans for OpenJDK is to deprecate and remove the 32-bit x86 port.

https://openjdk.org/jeps/501

It turns out that OpenJDK on illumos/Solaris still has a fair few remnants for 32-bit x86. It turns out that none of this has actually worked or been compiled in a very long time (8u20 I think was the last time it worked), so I'm going to completely strip any remaining 32-bit code out of my Solaris port.

At FOSDEM I noticed the @Luanti stand. Naturally, my first thought was like: "Cool? Can I get it running on Tribblix?"

Yup. I mean, it's obvious that nobody has tried to build it on illumos or Solaris before, but a handful of patches later and:

Because, well, it's there, I was trying to build jdk9 from source and got an entertaining failure.

Error: time is more than 10 years from present: 1420063200000
java.lang.RuntimeException: time is more than 10 years from present: 1420063200000

What it's doing here is generating currency data, and there's a sanity check that the data's reasonably up to date. (It only tripped over that 10 year threshold about a month ago.)

Ho hum. Sledgehammer time.

Xfce not enough? How about MATE running on SPARC Tribblix?

Can you run a graphical desktop on SPARC illumos? Here's an Xfce session running on Tribblix m31 on my T4-1.

(Yes, I'm cheating; the display server is Xephyr running on my x86 machine. But the applications are all running on the SPARC box.)

I'm sorry, this is getting a bit ugly now. But some of you might remember this (I've tried really hard to forget, but keep having flashbacks). Sure Open Look had a level of consistency and uniformity, but I found it uniformly terrible to use. But yes, it does sort of work on SPARC Tribblix - and the virual desktop version of olwm took away some of the extreme pain.

Going a bit retro now, Window Maker on SPARC Tribblix.

And the next amusing diversion, after getting a working startx back, it turns out that the option to set the display size differs between Xephyr and Xvnc

Xephyr -screen 1600x1200

vs

Xvnc -geometry 1600x1200

I was trying to pass -geometry to Xephyr, and it silently accepts it but it doesn't change the size of the display which confused me for a few minutes.

@sxa From the xclock man page:

BUGS
Xclock believes the system clock.

(I suspect defaulting to colour is a distro or user thing. With no customizations whatsoever, building from source gives me monochrome. I can get the colour version by running xclock -xrm '*customization: -color', although that option isn't available for xclock on Solaris 10 by the look of it. Still, that xrm setting will give you coloured apps if there's a color app-defaults file installed.)

Not being able to concentrate properly on writing code, I finished off some of my thoughts on Static Code Analysis

https://ptribble.blogspot.com/2024/12/thoughts-on-static-code-analysis.html

On of the key things I've noticed is that the biggest benefit of using tools is being made to go and look at your code.

So, can we use clang to build #openjdk on #illumos ? It compiles, but

# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000000000000, pid=16097, tid=2
#
# JRE version: (21.0.5) (build )
# Java VM: OpenJDK 64-Bit Server VM (21.0.5-internal-adhoc.ptribble.jdk21u-jdk-21.0.5-ga, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, solaris-amd64)
# Problematic frame:
# C 0x0000000000000000

Ah, well, that would indeed be problematic.