I finally got GnuTLS running, and it was segfaulting instantly upon load. Why?

Solaris this old does not have a /dev/random equivalent. Anywhere. At all. There's a patch to add it for 2.5 and 2.6, but not for 2.7. Why they didn't include it in 2.7 as well, I don't know, but the 2.6 packages work on 2.7. Speed isn't great, but fuck it, it works. Now to figure out how the fuck to get certificates without needing recent python3 or openssl (this excludes every single update-ca-certificates type package. Yes, for every distro.)

Also, I got X11R6 running, and the drivers even give me 2D acceleration on this T43. It's nice to have more than 16 colors again.

a couple complete asspulls to synthesize unsetenv and a few other things later, and we have SDL2 2.30.0. I can't test it, because everything that needs it requires cmake which is still busted because libstdc++ is still busted... but it compiled!

Speaking of, if you're gonna leave a check for setenv in your configure.ac because you can work around it, but you DON'T check for unsetenv, don't try to fucking use unsetenv!

ugh, the versioned symbols DO exist... in a custom table, and Solaris' linker gives up and returns the first file it sees when linking, so at COMPILE time libstdc++ is linked to /usr/lib/libm.so.1, but at RUNTIME it's pulling `$__OUTDIR/lib/libm.so.1`! (in this case `$__OUTDIR` is `/opt/newroot`)

# ldd -s /opt/newroot/lib/libstdc++.so

find library=libm.so.1; required by /opt/newroot/lib/libstdc++.so
search path=/usr/local/lib:/opt/newroot/lib:/usr/lib:/lib:/sbin/lib:/opt/SUNWspro/lib (LD_LIBRARY_PATH)
trying path=/usr/local/lib/libm.so.1
trying path=/opt/newroot/lib/libm.so.1
libm.so.1 => /opt/newroot/lib/libm.so.1
libm.so.1 (SUNW_1.1) => (version not found)
# mv /opt/newroot/lib/libm.so.1 /tmp
# sync
# LD_LIBRARY_PATH=/opt/newroot/lib:/usr/lib:/lib:/sbin/lib:/opt/SUNWspro/lib ldd -s /opt/newroot/lib/libstdc++.so

find library=libm.so.1; required by /opt/newroot/lib/libstdc++.so
search path=/opt/newroot/lib:/usr/lib:/lib:/sbin/lib:/opt/SUNWspro/lib (LD_LIBRARY_PATH)
trying path=/opt/newroot/lib/libm.so.1
trying path=/usr/lib/libm.so.1
libm.so.1 => /usr/lib/libm.so.1

you know a package is completely hosed when you have to modify like twelve files to get CFLAGS to be respected, and it's especially bad when the CFLAGS need to be respected because they've somehow fucked up includes enough to require explicitly passing "-I/usr/include"

wouldn't it be fucking hilarious if that package was gcc-4.3?

Ah, yes: dd from coreutils-9.7 DOES WORK... unless status is enabled, at which point it will segfault as it's taking "jd" from... the formatted strings, I think? and just taking that literally, and then segfaulting shortly after when trying to compute numbers against string "jd", which I'm surprised doesn't work, as I figured you COULD, in fact, just do calculations against a string...

The fun part is that it works fine otherwise, so I've been compiling things normally and correctly with a busted dd the whole time.

figured out why libgnu.a becomes trashed due to __eprintf being referenced but hidden: binutils 2.15 poisons gcc 3.2, which then cascades ALL the way up to gcc-4.3.6 before problems actually show up, when symbols support being hidden suddenly. There's a bug and everything, which was wontfixed and forgotten about 20 FUCKING YEARS AGO, and 5 years before the bug actually trips in gcc on sol7! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461

motherfuckers, all of them

The issue is more than this one bug, if you're dealing with this bug, this is how you fix it, as it starts at the very beginning of the non-Sun compiler stack:
- Don't use tgcware or sunfreeware packages. They're all poisoned in this way, and it causes issues compiling just about everything later down the line. Start with SUNWspro.
- Build binutils 2.13 before gcc 2.x, which is required for 3.x or higher anyway. SUNWspro will just barely suffice for this on Solaris 7.
- Build gcc 2.95.3, ENFORCE THE GNU BINUTILS. The docs say to use Solaris as+ld, this is a trap. Don't fall for it! Never use them unless there's strictly no other option.
- Build binutils 2.15, then gcc 3.2.3 (do not bootstrap.) Because gcc 2.95.3 isn't poisoned by the system linker, you'll be OK.
- As gcc 3.2.3 cannot be bootstrapped with 2.95.3 (despite that being the opposite of every doc in the universe about gcc being forced to bootstrap, gcc 2.95.3 is not capable of doing this) remove the GCC 2.x specific include dir in your prefix (3.2.3 won't do this itself) and immediately rebuild gcc 3.2.3 (with bootstrap-lean) to remove errant C++ behavior for later.
- Build binutils 2.17. 2.15 will build gcc 4.x and beyond, but this breaks libstdc++ permanently as it'll version symbols that do not exist. If "floor@@SUNW_1.1" symbol refs exist in a binary, you've hit this bug.
- Build gcc 4.2.4, disable bootstrap. (It will bootstrap anyway, but if you try to enable it, it'll break. This occurs with make 3.7 through 4.4, so it's a logic bug in gcc's autotools set.) As before, remove all 3.2.3-specific include directories (and $PREFIX/i386-pc-solaris2.7/assert.h, due to a CFLAGS bug in 4.2.4 through 4.6, and probably much further) and then immediately rebuild it with itself. (Again, disable bootstrap, it will anyway.)

At this point, if libstdc++.so has no references to __eprintf or floor@@SUNW_1.1, you're in the clear. More testing is needed to see if this persists through 4.6.x, the last versions with any measure of sol7 support, but i'll keep people posted.

`man /opt/SUNWspro/bin/cc`
"yes we have similar -O flags to GCC but no -OS or -Os"
ok, that's reasonable...

`-O1`
"WARNING: Passing '-1' to linker!"

so that was a fucking lie

i've gone ahead and rewritten 90% of my build system, and now I can build binutils-2.15 (kind of) but now gcc-3.2.3 is inconsistent on whether `ld` will SIGSEGV or not, and if it doesn't, tar-1.25 can't be built because it loses track of its own internal includes (alloca.h, part of libgnu), which it only tells me about at link time.

Nothing has changed in the env itself, I've got all kinds of debug output to make sure of that.

$ cat sys-patch.sh

#Go To Jail For Your Linker Crimes
mkdir -p /usr/jail
mv /usr/ccs/bin/as /usr/jail/as.orig
mv /usr/ccs/bin/ld /usr/jail/ld.orig

I've had friends suggest things during the duration of this project, some suggestions are helpful and some are very much not:

"Rebuild your scripts, they're ass and hard to maintain" - helpful, broke shit but needed done.

"You saw that one Unix book in that store, right? Buy it if it has the CD, i'll just give you the money." - Suspicious, but helpful, contained a lot of good hints and also seemingly lost versions of a lot of GNU software that I can bootstrap with suncc. archive.org listing soon.

"Just port glibc!" - trust me buddy, i've tried, it's not as easy as "add sysdefs lmao" like they make it out to be and they removed the ability to port it in like 2014

"Just port GCC <newest version>!" - god no could you imagine how fucking hard it would be to deal with the macro hell in there?

"Just use modern Linux" - not helpful, that's no fun.

"Use rust lmao" - not helpful, even taking it seriously I'd have to add full C98/C11/C++11 at minimum to build the vendored LLVM and if I could do that the issue would be over anyways.

"Build your own compiler equivalent to GCC <newest version>!" - i'm not smart enough to not fuck up the system headers, and you want me to do WHAT

i can't even build binutils-2.13.2.1 anymore, which came before GCC in general earlier.

i hate this shit dude it's rotting BEFORE MY EYES

Solaris 7 Pro Tip:
after installing XFree86 and getting it set up, use the following one-liner to get it to take over the display server:
`echo ":0 Local local_uid@console root /usr/X11R6/bin/X" > /usr/dt/config/Xservers && reboot`

(nowhere in the docs is this clear at all, and the docs lie in general.)