is gerrit broken again?

I can get to it ok

I have seen few messages but it appears to be ok still

illumos.org/issues/16880#change-47687 is a post from someone who just registered on illumos.org which has a final sentence that looks like SEO link spam

→ BUG 16880: pkglint fails on OpenIndiana with openssl mediator set to 3.1 (New)

ptribble: Are you around, by chance?

hi bahamat!

Hi!

Ok, so we're using your JDK17 for Jenkins. The latest update requires at least JDK 17.0.11, and the binaries you have are 17+35.

I was hoping you'd be able to build a 17.0.11-ga for us fairly easily?

And to complicate things, it needs to be able to run on 20181206T011455Z.

I'll check what the illumos symbol version is on that right now, but I don't remember what it is...

I'll figure that out bahamat

thanks

I presume 17+35 actually works? (Other than age.)

illumos-gate commit for the above SmartOS is 2f3d18f2c9

Yeah, it seemed to. The error I was getting is "sun.security.pkcs11.wrapper.PKCS11Exception: CKR_GENERAL_ERROR"

Libc was SYMBOL_VERSION ILLUMOS_0.28 {

When I asked in jenkins on matrix they said that there's been a bunch of updates and mine is too old.

Yeah, I can confirm that there were at least some of our agents running on your jdk17+35 that were working until this latest Jenkins upgrade.

So I'm building on something a bit newer, I think with ILLUMOS_0.40, but java is very conservative about the libc functionality it requires

Actually, I retract my confirmation...I'm not completely sure.

A couple I checked were actually on java11...

danmcd: What libc version is 20210826T002459Z?

If you look at the java binary with pvs it'll tell you what it requires.

Hang on...

pvs -d /usr/lib/libc.so.1 will get you that, probably pipe to head.

SYMBOL_VERSION ILLUMOS_0.39 {

[root@jenkins-462d490c-21-4-0 /opt/tools/java/openjdk17/bin]# pvs java

libc.so.1 (ILLUMOS_0.26, SUNW_0.7);

Yeah, makes sense that it has 0.26 given that was an accidental weak version.

( 20210826 libc is 0.39 )

OK, I actually have some with 17-internal+0-adhoc.ptribble.jdk17-jdk-17-35 and some with 17.0.11-internal+0-adhoc..jdk-il-jdk-17.0.11-ga

And pvs reports ILLUMOS_0.26 for both of them

Which means it's probably less than that but oops accidental weak version.

But maybe I can just copy it over and use it?

Should, yes.

At least from a libc perspective.

There are probably other shared objects outside of illumos it links against you may need to consider.

Ok, let's give that a shot and see what happens...

My 17+35 was really intended for people to build their own

I've put a copy of 17.0.13 at pkgs.tribblix.org/openjdk

Damn, no, that doesn't work.

ld.so.1: java: fatal: libc.so.1: version 'ILLUMOS_0.37' not found (required by file /opt/tools/java/jdk17-jdk-17.0.11-ga/bin/../lib/pkgsrc/libiconv.so.2)

Yeah, the thing is I need to be able to run it on ILLUMOS_0.28

And as far as I can tell (looking at all the objects) that 17.0.13 build only needs ILLUMOS_0.26

Ok, let me try that then

It's the libiconv that's pulling it in, not Java.

Beacuse that was built with stack protection.

So where did you get that libiconv bahamat?

Either the PI, pkgsrc-tools, or statically linked with java

Not statically linked.

The path says it's /opt/tools, so probalby tools pkgsrc.

Which to me says that you're trying to use too new a tools pkgsrc.

If it was staically linked, it wouldn't be calling out a different shared object.

That looks like a pkgsrc build shipped with some extra local copies of the 3rd-party libraries from pkgsrc

rmustacc: But libiconv hasn't changed version

I do'nt understand what you mean?

ld.so.1 says libiconv.so.2 requires 0.37 which is the version that introduced the stack protector in libc.

If you look at what java depends on, it depends on libiconv.so.2 and the libiconv.so.2 is what's too new to run on your platform.

OK, so that jdk17 came from pkgsrc

That's what you meant.

ptribble: that version of jdk17.0.13 works for me!

Awesome, thank you!!

Thanks ptribble, rmustacc, and bahamat!

Excellent!

And that was definitely faster than me picking apart dobuild until I got it to work on SmartOS :-D

bahamat: I assume you were using the 17.0.11 from us-central.manta.mnx.io/pkgsrc/public/pkg-bootstraps/index.html which was built on 20210826, and presumably on a platform older than that?

or did I somehow bundle the wrong libs?

I use that as the bootstrap for the openjdk21 build on the same OS so it should work..

so I have a set of changes that make java optional that come from arm64-gate, and just optionally amputate (because who's going to port java for me?)

would people like those upstream?

I don't like flags that slice off bits of build, but the java situation seems special, except for Peter being a super hero

it looks like: richlowe/illumos-gate 68dcbda

why that's showing some of sommerfeld's changes I don't know :\

That neatly identifies our dependencies on java, too

@richlowe our use of java isn't for SmartOS per se... it's for Jenkins agents.

All of this was because bahamat couldn't get one of her Triton component builds to work.

Although it may be worth asking (again) how much of the java stuff in gate is actually useful

Oh yes... SmartOS jettisoned that WELL before I starting working there.

I *thought* I had removed it all from Tribblix, besides resource pools, but looking at that change I missed some of the bits in the dtrace tests

As for illumos on arm64, I would like to have java there too.

And it's probably easier to support than sparc, because openjdk already have a fully supported aarch64 implementation

btw, we do have rising problem with java in illumos-gate, some of the code is already deprecated and once they stop supporting those functions.... I have been looking on some cases and those are definitely fixable, but require time (as usual).

and of course testing those bits is even more interesting.

I wouldn't worry about deprecated methods too much, unless they're actually deprecated for removal

What will hit eventually is the phasing out of JNI

If we look at the java usage the bigger things will be where do we actually rely on it from the core implementation ala poold.

I suspect the use of dtrace_jni and similar is minimal in practice.

ptribble: the real crime is availdevs, if someone with the energy just wanted to delete it

as best as we can tell, it's only used by installers that don't exist (and perhaps never existed, really)

(I filed the bug already at least once)

it's just always having something else to do in the way

And it can't possibly work on any current distro, because it's 32-bit and no distro ships a 32-bit java

then it is axe time:D

the problem with gardening, is sometimes you have to tend to what's alive before you can dead head

illumos.org/issues/15147 for availdevs

→ BUG 15147: remove /usr/lib/zfs/availdevs (In Progress)

It's assigned to you richlowe lol

ptribble: It doesn't actually use Java; it's so much worse than that.

jclulow: I can drop that for anyone who wants to delete the damn thing before I get to it!

I just looked at the code, it's ... a terrible concept

Yes

richlowe: huh? (didn't see anything of mine in that commit link you posted)

jperkin: Circling back...your build is fine. I copied it from a 2022 PI to a 2018 PI

sommerfeld: in my viewing it, (parts of) your ipv6 scope changes appeared in the diffs

Didn't see that when I looked at. Huh.