James Michael DuPont wrote:
Three concepts, not one
1. runtime
2. 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.
