https://sourceware.org/bugzilla/show_bug.cgi?id=17473
--- Comment #1 from Cary Coutant <ccoutant at google dot com> ---
> Minix3 builds Gold as part of its build process. When cross compiling on
> OSX10.9, it fails to build Gold with the following error:
>
> In file included from
> /Users/thomas/minix/tools/binutils/../../external/gpl3/binutils/dist/gold/binary.cc:31:
> In file included from
> /Users/thomas/minix/tools/binutils/../../external/gpl3/binutils/dist/gold/stringpool.h:23:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:438:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cwchar:107:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cwctype:54:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cctype:51:72:
> error: use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype'
> inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
> isalnum(__c);}
>
> This is fixed by #include'ing <sstream>.
How does including <sstream> fix the problem?
Neither binary.cc nor stringpool.h use any API from <sstream>, so I
don't see how this is an appropriate fix. Even if it does fix it
somehow, I don't see how that would be anything but an accident that
might break again at any point in the future.
Libiberty's safe-ctype.h is clearly doing something very dangerous
here, so it seems to me that there's a portability issue that needs to
be fixed there, not in gold.
Can you compile binary.cc (without your patch) with --save-temps, and
send me the .ii file?
-cary
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
