THERE WE FUCKING GO
this has taken so long to figure out, but apparently, bootstrapping can break shit. the docs sell it as a "do this if anything breaks" but apparently that in itself caused all sorts of issues.
also disabling multilib.
i'm under the impression that these macros are Just Not Present in GCC 4 but the only place I can find GCC 4-specific macro docs 503's AND i'm first to archive it. well... fuck.
multilib disabled: totally fine.
multilib enabled: SIGILL when compiling the "return 0" hundred-byte test ELF.
why are you like this
i need to port all of glibc. goddammit.
foreseen problems looking at the standard listing alone, not even glibc yet:
- fenv.h (this seems like it'll be heavily system-dependent, and since Solaris 7 doesn't always have float support at all... this one's gonna suck.)
- tgmath.h (might be liftable from other systems with minimal work, since it seems to only be type-agnostic macros?)
- any stdlib.h changes needed (am i gonna need to search for leaked kernel source or some shit for this one? iirc this one is heavily system-dependent...)
i'd imagine this gets worse the higher i go, so C11 may be off the table without assistance of someone more knowledgeable than my stupid ass.
great fucking sign that the docs on how to port your large library project don't make any sense. i can't figure out how to actually add system-dependent file overrides. supposedly, you put a folder somewhere in `sysdeps/` and it Just Works but I have no idea how to declare "yes, this target is supported" and just having the folder and basic file structure where it says to put it is not fucking cutting it.
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
ParzivalWolfram
Vint Prox