Not trolling, just a serious question: why can I compile any software from early 90's to today on any Linux distro I've attempted without issue? It sounds like I shouldn't be able to, but it takes less than 20 minutes of finagling to compile ancient POVray software from the 90's on literally any current Linux distro.
Technically, you can't. A lot of people were still using pre-ANSI C compilers in the early 1990's, so the code will be K&R C rather than ANSI C.
Any software that uses a function name or variable that uses what's now a keyword in C89 or later won't compile correctly, it'll barf. Try naming a function "void" or "restrict" or "const" or "volatile" or typdef'ing something named "_bool". Likewise, you should try compiling most of the contents of the comp.unix.sources archive, and noting the fact that -std=c89 requires ANSI C constructs, rather than K&R C constructs.
Global variables may be caches in registers in later compilers, while depending on changing a value from another thread of control (either a thread, or from a signal handler, etc.), where changing the backing value won't modify the register contents because the contents are not re-fetched on reference... i.e. compiling with a compiler that depends on the "volatile" keyword for the validity of its optimization assumptions (technically compiler writers could have introduced a "nonvolatile" keyword instead, but didn't because they wanted to lazily make the assumption and have the programmer correct it, rather than being conservative about their assumptions).
I expect that you will also see a lot of "cast discards qualifier", "comparison si always true" and similar warnings that would be errors, should you enable -Werror.
Additionally, you're going to find incompatibilities in the use of pty's, and in the use of trmio vs. termios, and other SVR4-ism's vs. BSD-isms (example: do system calls automatically restart after a signal handler fires, or do they terminate the function call with EINTR?). You will also find threads differences (such as PTHREADS_MUTEX_INITIALIZER) which will bear on your ability or inability to declare an initialized pthread_mutex_t, or need to call pthread_mutex_init(). You'll also find that OOB signalling on TCP/IP sockets behaves differently on BSD 4.2g based TCP implementation - and the code that expect a 4.2g sockets implementation - vs. later 4.3 sockets interfaces. For SVR3 and SVR4.0.2 code through 1994, you'll also see portability problems with ntoa vs. the libTLI interfaces, which lost out to the BSD interfaces for socket and host name lookup.
If you are using setuid/seteuid/etc., you will also find that older code assumes the non-existance of POSIX saved IDs - in other words, it believe that you can flip back and forth easily. Not only will this not work without jumping through an additional hoop, you're going to have security holes if you were to "fix" the system call interfaces to behave in the old way.
What you actually mean is that you haven't *noticed* any problems, in doing a not very exhaustive survey of older software. If you tried to use an older gcc that supported the K&R C dialect as a -std= argument, you'd find that the system header files with ANSI C prototypes wouldn't compile correctly.
That is not possible on Mac OSX (I've tried repeatedly, even with homebrew).
I would like to agree with you, maybe I don't understand what the problem truly is, but there is definitely a difference between compiling software for Linux vs Mac OSX. As in, one is so easy a talented kindergartener can do it, while the other is literally impossible without rewriting Mac OSX. Why is that?
Are you only trying to use POSIX interfaces on Mac OS X, or are you trying to use additional libraries supplied by the OS historically, but not supplied by the current OS version? If the answer is the latter, then the problem is that your software isn't portable, because it doesn't engage in minimal use of only standard-defined interfaces.
You should also be aware that Mac OS X is based on Rhapsody, which is a BSD 4.4 system. So the same setuid/signal/socket problems that apply to the comp.unix.sources archives on Linux, apply to compiling old code (which is going to assume BSD interfaces, rather than POSIX compatibility), are going to apply equally to Mac OS X as they do to Linux.