USES=compiler:c++11-lib on FreeBSD 8.4

[Tijl Coosemans]

On Mon, 28 Apr 2014 22:38:55 -0400 Geoff Speicher wrote:
> Not sure if ports is the right place for this post so apologies in advance
> if I'm not in the right place.
> 
> I'm porting an application that requires c++11, and I'm trying to create
> the port on a FreeBSD 8.4 box. From everything I have read, it appears that
> c++11 is only supported in 9.1+ when world has been built with the c++11
> toolchain. However, the various ports switches such as
> USES=compiler:c++11-lib don't yield any warnings on 8.4, yet don't seem to
> work either. Can anyone comment on whether or not this option is supposed
> to work on 8.4?
> 
> Taking ports out of the equation for a moment, I can't compile the
> following c++11 file:
> 
> // test.cpp
> #include <type_traits>
> #include <string>
> 
> int main() {
>   int number = 10;
>   std::string value;
>   value = std::to_string(number);
> }
> // EOF
> 
> clang++33 fails on a new c++11 include file:
> 
> $ clang++33 -std=c++11 test.cpp
> test.cpp:1:10: fatal error: 'type_traits' file not found
> #include <type_traits>
>          ^
> 1 error generated.
> 
> 
> g++47 at least finds the include file but doesn't appear to define
> std::to_string as it should:
> 
> $ g++47 -std=c++11 test.cpp
> test.cpp: In function 'int main()':
> test.cpp:7:11: error: 'to_string' is not a member of 'std'
> 
> I also tried installing devel/libc++ and that fails trying to include
> xlocale.h, which only appears to exist in 9.1 and later. Am I missing
> something here or is c++11 simply not supported on 8.4? Assuming the
> latter, is there a way to automatically make ports fail with a meaningful
> error message on <9.0 when attempting to use c++11-lang or c++11-lib?

On 8.x one of the gcc ports has to be used if you need a c++11 library,
but it appears that the declarations of to_string in bits/basic_string.h
are hidden behind #ifdef _GLIBCXX_USE_C99 and that macro isn't defined
on FreeBSD because we are missing a few obscure c99 functions.
I think it would be best to patch the gcc ports to force the definition
of that macro.