Failure to Build on OSX 10.12.1 using Apple Clang 800.0.42.1

[MoKob]

The preprocessor switch here results in a failing build for me on OSX 10.12.1.

The error provided:

/Users/mokob/git/engine/project-osrm/osrm-backend/third_party/sol2/sol2/sol.hpp:1394:9: error: use of undeclared identifier 'strerror_s'; did you mean 'strerror_r'?
        strerror_s(buf, 1024, en);
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/string.h:116:5: note: 'strerror_r' declared here
int strerror_r(int __errnum, char *__strerrbuf, size_t __buflen);

Removing the switch in favour of the GLIBC branch allows compiling just fine.

The compiler used in this case is:

Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.1.0

[ThePhD]

This is just one of those things where I hack more things into that definition that help me figure out which platforms have this dumb small name change in it that ruins compilation.

I added that branch there specifically because someone on a Linux machine was using a version of GLIBC that demanded strerror_s, and it's supposed to be defined by GLIBC only. Could you give me a clang++ -dM -E source_file.cpp so I can see the defines present? It'll help me figure out what might be defining __GLIBC__ and why, and what I should add to protect against it.

[danpat]

@ThePhD https://gist.github.com/danpat/1a7997639c3ef67d931353d497990f08

I work with @MoKob and I'm seeing the same problem, also on OSX.

Build command is:

clang++  -dM -E -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_RESULT_OF_USE_DECLTYPE -DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_TEST_DYN_LINK -DOSRM_PROJECT_DIR=/Users/danpat/mapbox/osrm-backend -DPROTOZERO_STRICT_API -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/Users/danpat/mapbox/osrm-backend/include -I/Users/danpat/mapbox/osrm-backend/build/include -isystem /Users/danpat/mapbox/osrm-backend/third_party/sol2 -isystem /Users/danpat/mapbox/osrm-backend/third_party/variant/include -isystem /Users/danpat/mapbox/osrm-backend/third_party/libosmium/include -isystem /usr/local/include -isystem /usr/local/include/lua5.1   -flto -Wall -Wextra -pedantic -Wuninitialized -Wunreachable-code -Wstrict-overflow=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fPIC -fcolor-diagnostics -ftemplate-depth=1024 -std=c++1y -stdlib=libc++ -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.10   -stdlib=libc++  /Users/danpat/mapbox/osrm-backend/build/check-headers/scripting_environment.cpp

Based on the docs at http://en.cppreference.com/w/c/string/byte/strerror it looks like strerror_s is supposed to be part of C11, and all the clang docs I can find say that C11 is the default for all recent versions. However, Bug.WellShit, that seems to be a lie.

strerror_r is the POSIX version of the function, and that definitely works on OSX, so maybe checking for POSIX with some combination of http://stackoverflow.com/a/11351171 is the way to go?

[ThePhD]

This shooould (?) be fixed in the latest. We use _POSIX_VERSION to tip us off that unistd.h is included. Pull from latest or download the single header here:

https://github.com/ThePhD/sol2/blob/develop/single/sol/sol.hpp

[danpat]

That seems to do the trick. Thanks so much for your awesome work, sol2 has saved us from luabind hell!

[MoKob]

Thank you for this quick fix from me as well. I really love these switches myself...