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
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!
ParzivalWolfram
