James Michael DuPont wrote:
Three concepts, not one 1. runtime2. operating system 3. architecture
Smart answer. And for win32 (and most likely anything else built for x86 architecture) architecture only has meaning when -march is specified in the build. The defaults used allow anything from i386 to i686 to be able to execute the binaries. If I specify -march=i686, then I've told the compiler to use optimizations based on that architecture, and the binary will therefore only execute on a platform that contains an i686 architecture. Given that, having the architecture in the file name only causes confusion because it isn't reflective of the binaries that are in it. Basing filenames on ``uname -m'' is just not smart, at least for win32.
All platforms have runtimes and sometimes may have options on what runtime is used. That is what we have here. We have a Windows 32 bit OS that has the OS vendor runtime of MSVCRT. Along comes a third party vendor with an alternate choice. So now other vendors have a choice, we must identify by filename those choices.
But wait, we have another TPV offering runtime support named MinGW. How does that differ from using the OS vendor supplied runtimes. Well for the C runtime, there is little difference. MinGW uses the MSVCRT runtime supplied by the OS vendor. We provide freely distributable versions of the headers and import libraries. However, we do provide a runtime extention, that is currently statically linked, to provide C99 compatibility. This is something that the OS vendor has said that will not do in the near future if ever. Given this, how should one proceed with naming files? IMO, that would be with the last segment of the triplet string returned by config.guess.
BTW, I mentioned above that there is little difference for the C runtime for MinGW; however, there is a big difference when it comes to C++. Interoperability between C++ objects of different vendors is currently not possible.
Earnie.