6 ms·

Ok, this will be my last try: "The libc headers across all the different weird Unix variants are 99% identical." This is both true and not applicable. The he

Ok, this will be my last try: "The libc headers across all the different weird Unix variants are 99% identical." This is both true and not applicable. The headers are nearly identical. The behaviors of the systems are not. Functions with the same name do different things, functions have different names but have slightly-incompatible shims with the name you expect, the headers have the function primitives but those functions are stubbed to NOPs in the actual library, and a million other things. These differences, furthermore, are not documented. All of the platforms you listed are meticulously documented and many of them have SDKs available. This, again, is not something that existed for many decades. If libc headers being close were so meaningful, widevine binaries would work on musl libc. They do not. Modern build systems work around these incompatibilities by declaring incompatible platforms unsupported and ignoring them. That's a perfectly valid business decision that makes everyone's lives easier! But it's not the only approach, and other approachs are valid too. Meanwhile, if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. I don't really understand your point in the last paragraph. Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that.

forrestthewoods 3y ago
Thanks for keeping it going. > if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. Yes, when you have differences in behavior you need to create an abstraction layer that behaves in a single, unified way. "The Right Thing" is to do that once ever for a given target. Write a bootstrap tool if you want. Or let one person spend one week testing and implementing shims for a brand new platform. Which is what you need to do anyways for embedded platforms that can't host the compiler. In any case don't force every user to run overly complex and brittle scripts when the result never changes for a given target. Oh hey, this is exactly what the source article argues! At least I'm not alone. > Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that. Bleh. ld is part of the GNU toolset. Pretend I said "standard Linux linking behavior". As you said, Linux's popularity stems from a collection of tools that work together nicely. The point I tried and failed to make is "compiling and linking doesn't have to be hard". Implementing an abstraction layer for a new platform isn't particularly hard either. Probably best to forget I said it. > this will be my last try: Thanks for the chat!

forrestthewoods 3y ago

Thanks for keeping it going. > if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms. Yes, when you have differences in behavior you need to create an abstraction layer that behaves in a single, unified way. "The Right Thing" is to do that once ever for a given target. Write a bootstrap tool if you want. Or let one person spend one week testing and implementing shims for a brand new platform. Which is what you need to do anyways for embedded platforms that can't host the compiler. In any case don't force every user to run overly complex and brittle scripts when the result never changes for a given target. Oh hey, this is exactly what the source article argues! At least I'm not alone. > Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that. Bleh. ld is part of the GNU toolset. Pretend I said "standard Linux linking behavior". As you said, Linux's popularity stems from a collection of tools that work together nicely. The point I tried and failed to make is "compiling and linking doesn't have to be hard". Implementing an abstraction layer for a new platform isn't particularly hard either. Probably best to forget I said it. > this will be my last try: Thanks for the chat!