Use CARGO_CFG_TARGET_ENV to determine if the target env ABI is gnu

[MarijnS95]

Fixes #30

The unfortunately named target_cfg used in a cfg() macro / attribute is a host flag (as all other cfg()s) when a build script using this library is compiled for the host. Instead, the ENV of the compile target should be read from an environment variable (just like $TARGET) when this code is being run on the host to figure out what the target environment ABI is.

This causes a cross-compile via xwin (reported in #30) to invoke the glibc compile test even though windows doesn't provide glibc. When cross-compiling to x86_64-pc-windows-msvc target_env will still be "gnu" while CARGO_CFG_TARGET_ENV properly represents msvc.

Aside from this I do think that the compile-check is valid for MSVC, the warning in that error even suggests to include <string.h>, but the test .c file already does exactly this... Perhaps the arguments set up by xwin and/or the sccache wrapper there are incompatible with how we invoke the compiler for this test?

[jean-airoldie]

The unfortunately named target_cfg used in a cfg() macro / attribute is a host flag (as all other cfg()s) when a build script using this library is compiled for the host. Instead, the ENV of the compile target should be read from an environment variable (just like $TARGET) when this code is being run on the host to figure out what the target environment ABI is.

Nice catch, I wasn't aware of this.

Aside from this I do think that the compile-check is valid for MSVC, the warning in that error even suggests to include <string.h>, but the test .c file already does exactly this...

Interesting, and slightly worrying.

[jean-airoldie]

/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/src/strlcpy.c(5,11): error: call to undeclared library function 'strlcpy' with type 'unsigned long long (char *, const char *, unsigned long long)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
(void)strlcpy(buf, "a", 1);

The weird part is that the compiler seems to correctly infer the strlcpy signature as taking a size_t (unsigned long long), despite the fact that we provided it with a ambiguous constant integer. From my understanding it would infer that 1 is a int if it didn't have the definition.

I'll merge this, and we'll wait and see if this fixes #30. Its possible that whatever causes our test to be unable to find the <string.h> symbols in #30 might also cause the same issue when libzmq is compiled.

[MarijnS95]

@jean-airoldie not to mention the return type of this function. Perhaps this is not the complete error context?