nope! this is even dumber. it turns out gcc in general is just stupidly sensitive to any tweaks in the system's headers, even adding whitespace can cause all of libiberty (as packed with gcc 4.4.7) to be invalid. almost every single line, starting halfway in. it looks like a missed semicolon or bracket, but the 120-some lines directly above are fine, the three header files it processed are OK, no one's to blame but a random macro that worked for 40 other lines but suddenly not here.

god i hate gcc

the modded header files even built binutils, xz, gzip, tar, m4, bison, gmp, and more just fucking fine, they all work, autoconf test suites are actually reporting fewer issues with the modded system headers than stock, almost all of it is now C99 compliant with very limited exception.

but if you add just whitespace to the headers, gcc 2.95.x loses track of all its builtins, 3.2.x can build just fine, and 4.4.7 can't bootstrap itself because it loses the ability to read in stage1, even when bootstrapping is disabled (because it does a one-stage bootstrap for its support libraries regardless.)

can't switch to a more sane language either because rust requires llvm and cmake, and those need like gcc 6.x and glibc, which are a ways off.

i've been laboring for WEEKS under the assumption that gcc-4.4.7 actually checks for --disable-bootstrap because it's in the docs and it SAYS it checks for it in the ./configure script, but i've just checked and they only actually check for --enable-bootstrap and if it's not present they just default to "yeah probably bootstrap". They never... actually... check.

Do you think they'd take patches for this old of GCC? This is some real dumb shit right here.

ok no ACTUALLY what they did is instead of being --enable-bootstrap or --disable bootstrap, SOME MOTHERFUCKER banged out enough shell script to require someone to PASS IT AS --enable-bootstrap=no

that is NOT how that shit works, please cease to be

4.2.4 suddenly works fine, but cannot bootstrap 4.4.7, because 4.4.7-stage2 goes from "libiberty is just trashed" to "gmp went missing" and i'm not sure why it doesn't check the fucking system includes directory because it's literally already there, it strips off $CFLAGS before stage3 which breaks shit, once again.

goddammit.

ok so bootstrapping 4.3.6 or 4.4.7 with 4.2.4 leads to stage2 losing gmp.h, it suddenly can't find it because it alters the include folder list. not bootstrapping 4.3.6 works fine initially, but then it can't handle define statements at all. not bootstrapping 4.4.7 isn't even possible, it ignores all possible switches related to bootstrapping.

fuck right off, gcc.

"gcc keeps losing track of includes by stage2 because it tosses out all cflags for stage2 onward of the mandatory bootstrap procedure"

at this point, fuck it, copy the entire system includes folder into the gcc folder. i don't care anymore. at this point i consider gcc an enemy combatant.

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.