[Bug gold/17473] Build error on OSX when building with Clang 6.0

[tveerman at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17473

--- Comment #2 from Thomas Veerman <tveerman at gmail dot com> ---
I was inspired by a thread [0] on the GCC mailing list where a similar error
message was produced, and it was suggested to move the include of <sstream>
higher up in the file. That 'fix' was actually meant to fix something entirely
else [1].

Now, why does this work? <sstream> includes <string>, which includes <cwchar>,
which in turn includes <cwctype> that finally includes <cctype>. cctype in the
OSX toolchain does among other things:

#ifdef isalnum
inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
isalnum(__c);}
#undef isalnum
inline _LIBCPP_INLINE_VISIBILITY int isalnum(int __c) {return
__libcpp_isalnum(__c);}
#else  // isalnum
using ::isalnum;
#endif  // isalnum

By including <sstream> before "safe-ctype.h", isalnum is not yet #defined and
so the #undef branch is taken. If safe-ctype is included it will redefine
isalnum to 'do_not_use_isalnum_with_safe_ctype'. However, safe-ctype first
includes <ctype.h> which includes <cctype>, so that shouldn't be a problem. But
the latter is only true for the GNU toolchain and I'm using OSX's toolchain
which doesn't have <ctype.h> (or I'm not looking in the right place). This
should normally fail, but I think the Gold build system when invoked from
Minix' build system picks up a <ctype.h> that's included by GCC (which is also
built by Minix). This <ctype.h> includes a <cctype> which has a different
header guard than the cctype in OSX toolchain.

binary.cc includes "stringpool.h" a few lines down of "safe-ctype.h", which
eventually  includes <string> -> <cwchar> -> <cwctype> -> <cctype> from the OSX
toolchain. Due to the inclusion of "safe-ctype.h" earlier, isalnum has now been
defined to 'do_not_use_isalnum_with_safe_ctype', and <cctype> while now take
the #ifdef branch and cause a compilation error. <cctype> is included twice due
to the difference in header guards.

Now, I didn't realize all of this when I made the patch, but since you asked
why it fixed the problem I investigated it. I agree it's dirty to include a
header that has nothing to do with the file. It appears that moving the
inclusion of "stringpool.h" above "safe-ctype.h" does the job as well.

[0] https://gcc.gnu.org/ml/gcc/2014-05/msg00006.html
[1] PR 61026 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026

-- 
You are receiving this mail because:
You are on the CC list for the bug.