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-se

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!