[johnnym]

I'll leave it at that lest I go ranting about why the PPC970 community in particular should have shut up.

I was tempted to say "challenge accepted" , but I don't have a that detailed knowledge about these POWER/PowerPC "infights" and having a hefty discussion here would also spoil this thread, I think. Though I really don't know why we can't have one and the other at the same time? Are there not enough people to keep both alive at the same time? You know, I look at all that work that went into it and can't understand why it's required to tear down one cathedral to build another one that has its windows upside down. Don't get me wrong, I'm happy for the other cathedral (the one with the windows upside down), too, but why does the other one have to go for that.

---

I also did some work on OpenBSD/sgi since my last post about it:

1. I tested the created 7.0 userland (incl. the recreated kernel) on my Octane with the help of nfsrb2 and it boots fine, the same way as the last "original" 6.9 version does and the same way the respective octeon file systems did.
   
   There is one issue with this release though: You remember that I decided to not build LLVM/clang because it takes much longer than the userland and kernels alone. It looks like the extra software that is available for octeon (and that was available for sgi, too,in the past) through the ports tree (e.g. from https://ftp.eu.openbsd.org/pub/OpenBSD/7...es/mips64/) is built with LLVM/clang, so seems to require the LLVM/clang libraries to run:
   
   
   Code:

   octane# pkg_add nano
quirks-4.53 signed on 2021-10-06T15:02:34Z
quirks-4.53: ok
nano-5.8:libiconv-1.16p0: ok
Can't install gettext-runtime-0.21p1 because of libraries
|library c++.8.0 not found
| not found anywhere
|library c++abi.5.0 not found
| not found anywhere
Direct dependencies for gettext-runtime-0.21p1 resolve to libiconv-1.16p0
Full dependency tree is libiconv-1.16p0
Can't install nano-5.8: can't resolve gettext-runtime-0.21p1
Couldn't install gettext-runtime-0.21p1 nano-5.8
   
   Well, as bad as this looks, the solution is to just copy over the missing LLVM/clang libs from an octeon userland or the respective set. I assume it's in the base set, because if it was in the comp(iler) set, software from the ports tree wouldn't work without the comp set installed:
   
   
   Code:

   octane# cp -v /tmp/llvm-libs/* /usr/lib/
/tmp/llvm-libs/libLLVM.so.6.0 -> /usr/lib/libLLVM.so.6.0
/tmp/llvm-libs/libc++.a -> /usr/lib/libc++.a
/tmp/llvm-libs/libc++.so.8.0 -> /usr/lib/libc++.so.8.0
/tmp/llvm-libs/libc++_p.a -> /usr/lib/libc++_p.a
/tmp/llvm-libs/libc++abi.a -> /usr/lib/libc++abi.a
/tmp/llvm-libs/libc++abi.so.5.0 -> /usr/lib/libc++abi.so.5.0
/tmp/llvm-libs/libc++abi_p.a -> /usr/lib/libc++abi_p.a
/tmp/llvm-libs/libcompiler_rt.a -> /usr/lib/libcompiler_rt.a
   
   I just copied everything I thought was related to LLVM/clang and that seems to have solved that issue:
   
   
   Code:

   octane# pkg_add nano
quirks-4.53 signed on 2021-10-06T15:02:34Z
nano-5.8:gettext-runtime-0.21p1: ok
nano-5.8: ok
octane# pkg_add htop
quirks-4.53 signed on 2021-10-06T15:02:34Z
htop-3.0.5pl20210418:libffi-3.3p1: ok
htop-3.0.5pl20210418:pcre-8.44: ok
htop-3.0.5pl20210418:xz-5.2.5: ok
htop-3.0.5pl20210418:sqlite3-3.35.5p0: ok
htop-3.0.5pl20210418:bzip2-1.0.8p0: ok
htop-3.0.5pl20210418:python-3.8.12: ok
htop-3.0.5pl20210418:glib2-2.68.4: ok
htop-3.0.5pl20210418:desktop-file-utils-0.26: ok
htop-3.0.5pl20210418: ok
Running tags: ok
New and changed readme(s):
    /usr/local/share/doc/pkg-readmes/glib2
   
   The binaries I tested from the ports tree - i.e. nano, htop, git, 7z, eopenssl-3.0 - installed and worked just fine after copying the LLVM/clang libs over.
   
   So that is not the perfect solution I had hoped for, but for now I can live with it. And maybe if some people with more powerful machines chime in in the future, we can bring LLVM/clang back to OpenBSD/sgi, though I'm unsure if it is worth the time for compilation, if we could otherwise just copy over some files to make it work with the software from the ports tree.
   
   
2. I had another idea to tackle the IP28 problem that arose in OpenBSD/sgi 7.2: I don't know how to debug that problem any further without the help of some person with more skills here, but I could do some bisecting to chase down a possible cause. Up until now that wasn't possible, because I use different branches for each version of OpenBSD/sgi and added the needed reverts and adaptations on top. But what if I could make all these changes in one branch and at the time they happened or not happened actually:
   Enter the sgi-never-retired branch, where I rewrote the history of the official OpenBSD source and "deleted" the commits that removed sgi stuff and adapted the commits that changed functionality that also needed to changed in the now still existing sgi related code. I will make another post about how to do that with git when I reached 7.2 in that branch. At the moment I am at 7.1 still. When I have reached 7.2 I can also finally start with the bisecting process and hopefully narrow things down to a reasonable commit, fingers crossed.