we've gone from "lol get rekt" to "we're most of the way through but we slipped up last second due to a bug in a generated makefile", so i might actually pull glibc out of my ass. one thing i don't understand, however, is why there's reference to so many solaris2.x files in the glibc package from 1999 to today, with the reference count going up over time, but it references an entire folder of solaris 2.x code that ISN'T PRESENT. i have a full directory listing for these files over time because they're in the translation files in every goddamn release since 1999 and the configure script even tries to search for them but WHERE ARE THEY

"sysdeps/unix/sysv/sysv4/solaris2" doesn't exist. "sysdeps/unix/sysv/sysv4" doesn't exist.
the korean translation files point to seven different header files IN THE SOLARIS2 FOLDER in 2006, and thirty-two files in 2023. THE FOLDER IS NOT HERE.

if compilation fails somewhere in gcc's includes, usually there's an issue with your code.

if compilation fails somewhere in gcc's includes in THIS mess, usually it ends up being a processor-specific nightmare.

today's bug:

`extern char *gettext(const char *);` from libintl is a syntax error near "const". no, no preceding lines have fucked up nesting or unterminated lines and there's no preprocessor statements directly before this line. it's just fucked, but ONLY on the original Pentium through the Pentium MMX. 486? Pentium 2 Xeon? Totally fine.

we have broken the 2015 average let's fucking go

(for those wondering what the 1997 package is, it's mc, then next oldest is 2001 wget

build one package, six more break. libiconv has been REBUILT FROM SCRATCH but no, no it's not sufficient, fuck you the symbols are RIGHT THERE in /usr/lib/libiconv.so FUCK YOU tar i swear to god

even if i manually declare the library AND redeclare /usr/lib as a library folder it still does this. i'm building with both shared and static libs, both are present for libiconv. but no, fuck me i guess

so i'm now compiling gcc 4.4.7 twice (once to get gcc 4.x itself, a second time after getting high enough with binutils for visibility support) and now i'm on to glibc.

predictably, it's a nightmare of non-standard include issues and "oh i need a semicolon or something in the middle of this typedef" in the middle of gcc extension black magic and dense preprocessor logic. i'm using glibc 2.14.1, which is the last version before they started stripping out non-Linux support entirely over the next couple versions. i might have to start fucking mixing files from other versions to get something resembling normal operation.

also, if you require inline support and optimizations to be enabled, glibc, MAYBE DON'T OVERWRITE THE USER'S CFLAGS

some of these hardcode ksh commands but aren't ksh compatible, which is fucking ffffffffFFFFFFFFFUN

of course my first thought is to try zsh because it's supposed to have stemmed from ksh, and be generally compatible, but NO. newest version of zsh CAN'T BE USED FOR MAKE

how does anyone take this shell seriously

- fdlibm (written by sun): needs stdint.h, completely broken (tries to build m68k libm on x86 machine)
- openlibm: needs stdint.h, IEEE float support fucked in all versions
- freebsd msun: based on fdlibm, might work?
- musl: requires Linux-style usage, might not be compatible?
- CRlibm/MetaLibm: fucking dead, can't find tarballs

we're at the point in the project where one merely considers writing completely custom C98 headers for the system. will they work? probably not, but we're gonna fucking try!

ok so if <newroot>/lib isn't symlinked to /usr/lib, gcc's first build immediately dies due to not being able to find __builtin_va_alist. HOW? IT'S FUCKING BUILTIN, GCC

it's not even like it's due to the prebuilt GCC needing it, because /usr/lib contains ZERO includable files, so it wouldn't be affected by /usr/lib not being linked, right?

but it is.

why and how

somehow, in trying to fix the type mismatch between SIZE_MAX and size_t, i forgot you can use typedef'd types... as types you can cast to!

i'm fucking stupid i swear

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.