#282 _MSC_VER and __CRT_INLINE

[Jack Applegame]

Compiler inserts visible standard library functions into object files when _MSC_VER macro is defined:

gcc -O2 -D_MSC_VER -c x.c
gcc -O2 -D_MSC_VER -c y.c
gcc -o a.exe x.o y.o
y.o:y.c:(.text+0x0): multiple definition of `_strncasecmp'
x.o:x.c:(.text+0x0): first defined here
y.o:y.c:(.text+0x10): multiple definition of `_strcasecmp'
x.o:x.c:(.text+0x10): first defined here
ld.exe: x.o: bad reloc address 0x7 in section `.text.startup'
collect2.exe: error: ld returned 1 exit status

[Jack Applegame]

// x.c
#include <string.h>
int fy(void);
int main() {
fy();
strcmp("Hello", "World");
return 0;
}

// y.c
#include <string.h>
int fy(void) {
return strcmp("Hello", "World");
}

[Jack Applegame]

x.c and y.c

[Ozkan Sezer]

_MSC_VER is defined by MS Visual C compiler to identify itself. You aren't supposed to define _MSC_VER by yourself, and most definitely not when using gcc.

[Jack Applegame]

But why mingw checks this macro? Some libraries uses _MSC_VER for internal purproses. For examle zziplib.
mingw.org build compiles with _MSC_VER without any problem.

[Ozkan Sezer]

We check that macro because we have some experimental support for compiling our CRT using MSVC. Mingw.org doesn't check that macro because they don't support MSVC at all.

[Jonathan Yong]

Regardless of whether other applications define it, _MSC_VER is for Visual Studio, you'd expect something that defines it to act like it. Unfortunately, this does not include GCC or mingw in general.