Hi jrmarino, about Illumos

[hoper-a11y]

Pardon me if it's the wrong place for that.

Illumos is broad, not just another variant of Solaris 10. Currently you only allow using binary built on your Solaris 10u8 server to keep it portable across the Illumos system. I think you should lift this limitation. First, currently there are too few packages. Second, Illumos has diverted too much from the original Solaris 10. I have one example for you: they replaced libdemangle and develop their own libdemangle-sys. This caused the openjdk package from Joyent's pkgsrc to break on latest OpenIndiana. I think the same thing would happen with raven, as raven was built on even older system than the SmartOS version Joyent used to build their pkgsrc packages.

Please split Illumos and Solaris because they are no longer the same. For Illumos:

DilOS already uses APT, they use a tool to convert OpenIndiana's IPS package to DEB.

Tribblix already uses SVR4 package, they also use a tool to convert OpenIndiana's IPS package to DEB.

SmartOS already have pkgsrc.

All of them don't need raven. So there only left OpenIndiana and OmniOS, both used IPS. My idea is untested but I think packages built on OpenIndiana will also work on OmniOS.

So if you want binary package for Illumos, please build it on OpenIndiana. Don't use Solaris 10u8, please. OpenIndiana has modern toolchain and will let a broader range of packages possible to build compared to the old Solaris 10u8.

You still have Solaris 10 as a separate target so you will lost no customer but indeed have more.

And yes, please allow building from source (ports) on Illumos, too. Binary only is too limited.

Please let me know what you think.

[hoper-a11y]

What makes you think /raven/toolchain/bin/ld is the gnu linker?

If it's not so it's the linker you folked from OmniOS here: https://github.com/jrmarino/sun-linker ?

It's causing problems! Have a look at it!

[jrmarino]

no, sun-linker was abandoned. that bin/ld is just a forking program. It passes all the arguments to the selected linker. passing a "--version" switch to it should tell you what it's invoking.

[hoper-a11y]

no, sun-linker was abandoned. that bin/ld is just a forking program. It passes all the arguments to the selected linker. passing a "--version" switch to it should tell you what it's invoking.

It's actually using gnu ld!

/raven/toolchain/bin/ld --version GNU ld (GNU Binutils) 2.34 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.

[hoper-a11y]

gnu ld on OpenIndiana is /usr/bin/gld.

Here is the output of gld --version:

gld --version GNU ld (GNU Binutils) 2.34 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.

Exactly the same! I don't know why it pick up the gnu linker at all!

[hoper-a11y]

Here is the output of /usr/bin/ld --version:

ld --version ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1763 (illumos)

[jrmarino]

okay, this may be a difference between the build environment and real installs. I'll take a look. It might be a logic bug.

[jrmarino]

you can probably work around this by overwriting that file with: http://www.ravenports.com/catalog/bucket_54/ravensys-utils/standard/ the ld program

[jrmarino]

but that might try to access a copy of the s10u8 linker which you probably don't have

[jrmarino]

so for a workaround you can try copying /usr/bin/ld to /raven/toolchain/bin/ld that might work.

[hoper-a11y]

you can probably work around this by overwriting that file with: http://www.ravenports.com/catalog/bucket_54/ravensys-utils/standard/ the ld program

Where does this package installed it binaries? Is it /raven/toolchain/x86_64-raven-solaris2.10/bin ?

If it's so, then it doesn't work. The output of /raven/toolchain/x86_64-raven-solaris2.10/bin/ld --version is here:

/raven/toolchain/x86_64-raven-solaris2.10/bin/ld --version GNU ld (GNU Binutils) 2.34 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.

[hoper-a11y]

so for a workaround you can try copying /usr/bin/ld to /raven/toolchain/bin/ld that might work.

This works as expected.

[hoper-a11y]

Aha, libdemangle stuff again! pkgsrc still has trouble with it!

At first, when I attempted to install openjdk8, it failed with:

pkgin install openjdk8 calculating dependencies...done. /usr/lib/amd64/libdemangle.so.1, needed by openjdk8-1.8.252nb2 is not present in this system.

This symlink fixed it:

ln -s /usr/lib/amd64/libdemangle-sys.so.1 /usr/lib/amd64/libdemangle.so.1

Here is the output of java -v:

java -version openjdk version "1.8.0_252-internal" OpenJDK Runtime Environment (build 1.8.0_252-internal-pkgsrc_1.8.252nb2-b00) OpenJDK 64-Bit Server VM (build 25.252-b00, mixed mode)

A big plus for Joyent is they always provide the latest openjdk, the system's openjdk is:

java -version openjdk version "1.8.0_232-internal" OpenJDK Runtime Environment (build 1.8.0_232-internal-oi-jdk8u-jdk8u232-b09.1-b00) OpenJDK 64-Bit Server VM (build 25.232-b00, mixed mode)

They also managed to packaged openjdk10 and openjdk11, which unavailable even on the system's IPS repo!

But openjdk11 has trouble with libdemangle again:

/opt/local/java/openjdk11/bin/java -version Error: dl failure on line 597 Error: failed /opt/local/java/openjdk11/lib/server/libjvm.so, because ld.so.1: java: fatal: libdemangle.so.1: open failed: No such file or directory

It seemed it has hard dependency on the old libdemangle that can't be replaced by the new libdemangle-sys.

ldd on the openjdk8's libjvm.so:

ldd /opt/local/java/openjdk8/jre/lib/amd64/server/libjvm.so libsocket.so.1 => /lib/64/libsocket.so.1 libsched.so.1 => /usr/lib/64/libsched.so.1 libdl.so.1 => /lib/64/libdl.so.1 libm.so.2 => /lib/64/libm.so.2 libthread.so.1 => /lib/64/libthread.so.1 libc.so.1 => /lib/64/libc.so.1 libdemangle.so.1 => /usr/lib/64/libdemangle.so.1 libkstat.so.1 => /lib/64/libkstat.so.1 libumem.so.1 => /lib/64/libumem.so.1 libssp.so.0 => /opt/local/gcc9/x86_64-sun-solaris2.11/lib/amd64/libssp.so.0 libnsl.so.1 => /lib/64/libnsl.so.1 libcustr.so.1 => /lib/64/libcustr.so.1 libgcc_s.so.1 => /opt/local/gcc9/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1 libmp.so.2 => /lib/64/libmp.so.2 libmd.so.1 => /lib/64/libmd.so.1

ldd on the openjdk11's libjvm.so:

ldd /opt/local/java/openjdk11/lib/server/libjvm.so libdl.so.1 => /lib/64/libdl.so.1 libthread.so.1 => /lib/64/libthread.so.1 libsocket.so.1 => /lib/64/libsocket.so.1 libsched.so.1 => /usr/lib/64/libsched.so.1 libdoor.so.1 => /lib/64/libdoor.so.1 libdemangle.so.1 => /usr/lib/64/libdemangle.so.1 libdemangle.so.1 (SUNW_1.1) => (version not found) libnsl.so.1 => /lib/64/libnsl.so.1 libkstat.so.1 => /lib/64/libkstat.so.1 libumem.so.1 => /lib/64/libumem.so.1 libstdc++.so.6 => /opt/local/gcc9/x86_64-sun-solaris2.11/lib/amd64/libstdc++.so.6 libm.so.2 => /lib/64/libm.so.2 librt.so.1 => /lib/64/librt.so.1 libssp.so.0 => /opt/local/gcc9/x86_64-sun-solaris2.11/lib/amd64/libssp.so.0 libgcc_s.so.1 => /opt/local/gcc9/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1 libc.so.1 => /lib/64/libc.so.1 libcustr.so.1 => /lib/64/libcustr.so.1 libmp.so.2 => /lib/64/libmp.so.2 libmd.so.1 => /lib/64/libmd.so.1

Unfortunately, ravenports seemed to not packaged openjdk on SunOS at all!

Disclaimer: I'm not in favor of Joyent here. They have a big advantage compared to ravenports because they are also the developer of SmartOS, an Illumos based OS! Our ravenports is pretty much a cross platform ports system and as you said ravenports on SunOS currently is just a single man's work. I think after we split up the Solaris 10 and Illumos target we could have openjdk build for us and packaged!

[hoper-a11y]

Updated to the latest bootstrap and ravensw worked very well on my OpenIndiana. There is no segmentation faults. Everything went just smooth as on FreeBSD/DragonflyBSD. I will test the latest bootstrap on OmniOS and report soon.

[hoper-a11y]

OmniOS has packages for both clang 8, 9 and 10. But I found clang 9 and 10 switched to compiler-rt (libc++ and libc++abi) failed to compile my test.cpp:

test.cpp:1:10: fatal error: 'iostream' file not found

include

     ^~~~~~~~~~

1 error generated.

This is OmniOS's own packaging problems as I have showed Joyent's clang version, also switched to use compiler-rt too, compiled my test.cpp without problems.

Clang 8, on the other hand, still uses GCC's libstdc++ so it compiled my test.cpp without any problems:

clang -v clang version 8.0.1 (tags/RELEASE_801/final) Target: i386-pc-solaris2.11 Thread model: posix InstalledDir: /opt/ooce/bin Found candidate GCC installation: /opt/gcc-8/lib/gcc/i386-pc-solaris2.11/8.3.0 Selected GCC installation: /opt/gcc-8/lib/gcc/i386-pc-solaris2.11/8.3.0 Candidate multilib: .;@m32 Candidate multilib: amd64;@m64 Selected multilib: .;@m32

The default version of gcc on OmniOS is 8.3.0 (I'm using OmniOS LTS):

gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-8/libexec/gcc/i386-pc-solaris2.11/8.3.0/lto-wrapper Target: i386-pc-solaris2.11 Configured with: /data/omnios-build/omniosorg/r151030/_build/gcc-8.3.0/gcc-8.3.0/./configure --prefix=/opt/gcc-8 --host i386-pc-solaris2.11 --build i386-pc-solaris2.11 --target i386-pc-solaris2.11 --with-boot-ldflags=-R/opt/gcc-8/lib --with-gmp-include=/usr/include/gmp --with-ld=/bin/ld --without-gnu-ld --with-as=/usr/bin/gas --with-gnu-as --with-build-time-tools=/usr/gnu/i386-pc-solaris2.11/bin --enable-languages=c,c++,fortran,lto --enable-plugins --enable-__cxa_atexit --enable-initfini-array --disable-libitm enable_frame_pointer=yes --disable-bootstrap --with-boot-cflags='-g -O2' --with-pkgversion='OmniOS 151030' --with-bugurl=https://omniosce.org/about/contact Thread model: posix gcc version 8.3.0 (OmniOS 151030)

As I have said, pkgsrc support is very good on OmniOS, they even has a pkgsrc branded zones. So it's nothing surprise that the pkgsrc packaged compilers work seamlessly.

ravenport's new bootstrap also worked very well. ravensw installed both gcc9-complete-standard and clang-complete-standard without any problems. The packaged compilers also worked fine after I applied the trick to /raven/toolchain/bin/ld :

mv /raven/toolchain/bin/ld /raven/toolchain/bin/ld.old cp /usr/bin/ld /raven/toolchain/bin/ld

[hoper-a11y]

It's interesting. I found Joyent's clang 10 compiled binary is very bloated.

Unstripped binary compared to others:

-rwxr-xr-x 1 root root 13304 Jun 19 15:51 test1 -rwxr-xr-x 1 root root 89896 Jun 19 15:51 test2 -rwxr-xr-x 1 root root 14192 Jun 19 16:05 test3 -rwxr-xr-x 1 root root 13632 Jun 19 16:05 test4

Stripped binary compared to others:

-rwxr-xr-x 1 root root 9360 Jun 19 16:20 test1 -rwxr-xr-x 1 root root 75032 Jun 19 16:06 test2 -rwxr-xr-x 1 root root 9904 Jun 19 16:06 test3 -rwxr-xr-x 1 root root 9512 Jun 19 16:06 test

test1 is Joyent's g++9 compiled binary. test2 is Joyent's clang-10 compiled binary. test3 is ravenports' g++9 compiled binary. test4 is ravenports' clang-10 compiled binary.

You see, it's too big for a hello world kind of program to be 89896 KB in size, after being stripped it's 75032 KB in size. The binary is not statically linked, it's dynamically linked (89896 KB is still ridiculously big for a statically compiled program of this kind):

file test2 test2: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available

[hoper-a11y]

Now I found ravensw is on par with pkgin on SunOS. After the Solaris 10 and Illumos target are split up I think ravenports could compete with pkgsrc pretty well.

[hoper-a11y]

Update: the libdemangle stuff is still a major problem for pkgsrc. My symlink can't fix it. Their openjdk8 java apart from printing the correct version info when checked with java -version can't work when running a jar file. I tested with pixelitor and it failed. It's useless!

I think ravenports would have the same problems if we could got openjdk to build and packaged it at all. The only solution is to have a separate repo for each Illumos distro.

[jrmarino]

i missed something. what path is illumos-distro specific that requires one repo per illumos to get openjdk to work?

[hoper-a11y]

I found the meta package xorg-single-standard is missing on SunOS. I have to install piece by piece and finally have a twm based desktop only from ravenports. No display manager so far, just startx from the terminal. I tried with fluxbox but it failed to start. So far just twm. I searched for xfce4 but it's incomplete. There is also no meta package for it on SunOS. The day we could build an entire desktop just by software installed from ravenports is still too far.

[hoper-a11y]

i missed something. what path is illumos-distro specific that requires one repo per illumos to get openjdk to work?

libdemangle stuff. On old Solaris 10 and old Illumos, the proprietary libdemangle is used. Modern Illumos like OpenIndiana replaced libdemangle with their new libdemangle-sys written from scratch. So stuffs that depends on the old libdemangle will break on newer Illumos. This is just one example of incompatibility between the old system and the modern system. Not only openjdk but other software might be, too. Did you notice some software can't be built on your old Solaris 10u8 box? If you split Solaris 10 and Illumos but still keep an common old enough Illumos system to build for all of the newer Illumos systems, you are basically do the same as Joyent and will suffer the same limitation as them. So our safest bet is each repo for each distro. As I have said, it will consume much resource but can't give back profit immediately. If you can't endure this, just support OmniOS first. If there are enough users, we extend to cover other distros, too. BTW, thanks to the zones features of Illumos, you could have just one OmniOS build server that build for all of the distros just utilizing zones, including Solaris 10, too. This is just in theory, I have never tried to do this myself. My zones are mostly run the same OS as the host.

[jrmarino]

so could we use the same libdemangle (building it ourselves if necessary) in solaris 10u8? just thinking out-loud

[hoper-a11y]

If you managed to find some way to keep compatibility across the distros, you could continue to provide software for them all just from a single common repo like you currently do. It's all about the software!

[jrmarino]

openjdk is conspicuously missing from RP because of the ungodly amount of patches it requires, especially for BSD. And it's a nightmare to maintain. We can't avoid it forever and it's on the wish list but that's the reason.

[hoper-a11y]

so could we use the same libdemangle (building it ourselves if necessary) in solaris 10u8? just thinking out-loud

I don't know. But I have the same thought as you. Why don't just test it?

More info about libdemangle-sys:

https://www.illumos.org/issues/6375

https://github.com/jasonbking/sysdemangle

It seemed libdemangle-sys was already integrated into the illumos-gate source tree. You could have a look at it.

[hoper-a11y]

openjdk is conspicuously missing from RP because of the ungodly amount of patches it requires, especially for BSD. And it's a nightmare to maintain. We can't avoid it forever and it's on the wish list but that's the reason.

I know this. Newer openjdk than openjdk8 also failed to compile on OpenIndiana because of unsupported system error! It's the reason why they don't have it on their repo. Joyent tried to have newer openjdk for their SmartOS. I don't know if it worked for them or not, it's just not work for me on OI.

[jrmarino]

I've got gcc7 fixed so that it works when installed on sunos. The same fix will work for the newer versions as well. I'm working on those today.

[hoper-a11y]

If it's too hard to have openjdk working on SunOS, I think just continue to postpone it until a large number of users explicitly asked for it. Even OpenIndiana themselves only have an outdated version on their repo. The whole Illumos ecosystem seemed to switch to NodeJS now. It seemed they also know that Java no longer cared about them! As I know Joyent is pretty much a NodeJS firm!

[hoper-a11y]

Supported platforms by OpenJDK: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

Summary: Linux, Windows, Mac and proprietary Unix (AIX, Solaris 11 SPARC only).

I think their focus switch to NodeJS is right! Java only remains as part of their build system. To build illumos-gate, you will need to have Java!

[hoper-a11y]

I've got gcc7 fixed so that it works when installed on sunos. The same fix will work for the newer versions as well. I'm working on those today.

Thank you for that. BTW, I had my new job. This mean I can't help testing ravenports on Illumos anymore. Sorry. I will have a close look at the project, though. Bye.

[jrmarino]

thanks.

[ghost]

@hoper-a11y There is no need to backport libdemangle-sys to Solaris 10u8. We can get the old libdemangle on OpenIndiana by installing the package sunpro. Don't let this trivial problem blocks us from shipping openjdk!