Bug 88766

Is this a really old compiler? tr1 has been in gcc for quite a while. In any case, there's no nouveau kernel support on FreeBSD ATM, so this isn't a huge issue.

The error was seen on FreeBSD 10 with clang 3.4.

Removing the tr1 namespace fixes the build errors.

Created attachment 112757 [details] [review]
Remove tr1 namespace.

(In reply to Vinson Lee from comment #3)
> Created attachment 112757 [details] [review] [review]
> Remove tr1 namespace.

That would require C++11 support, which I feel a lot worse about requiring than having nouveau not compile with clang. I'm surprised that clang chose not to ship tr1 headers... oh well.

If someone maps out the various version support for all this, perhaps we can make a decision. Or some other approach is the standard way to deal with this?

(In reply to Ilia Mirkin from comment #4)
> (In reply to Vinson Lee from comment #3)
> > Created attachment 112757 [details] [review] [review] [review]
> > Remove tr1 namespace.
> 
Hi Ilia,

> That would require C++11 support, which I feel a lot worse about requiring
> than having nouveau not compile with clang. I'm surprised that clang chose
> not to ship tr1 headers... oh well.
> 
Actually I suspect your platform support would increase by relying on
the C++11 standard library rather than an on a non-standard extension.
Most likely this bug is not caused by the Clang compiler itself, but by
the standard library implementation.  Apparently FreeBSD ships with
LLVM's libc++ as default implementation these days, which implements the
C++11 standard library and doesn't attempt to support the TR1 namespace,
which is a C++03-specific extension.

> If someone maps out the various version support for all this, perhaps we can
> make a decision. Or some other approach is the standard way to deal with
> this?

I'd suggest we apply Vinson's patch and then build the codegen back-end
with -std=c++0x (available on GCC 4.3 and later), otherwise GNU's
libstdc++ will emit an error if you include any of the C++11 headers
while building in C++98/03 mode.  -std=c++11 would work too but it's
only supported since GCC 4.7.  Any reasonably recent Clang version (at
least 2.9) should support both switches.

(In reply to Francisco Jerez from comment #5)
> Most likely this bug is not caused by the Clang compiler itself, but by
> the standard library implementation.  Apparently FreeBSD ships with

Yes, absolutely.

> LLVM's libc++ as default implementation these days, which implements the
> C++11 standard library and doesn't attempt to support the TR1 namespace,
> which is a C++03-specific extension.

OK. nouveau doesn't work on FreeBSD; any reason for me to care about it?

> 
> > If someone maps out the various version support for all this, perhaps we can
> > make a decision. Or some other approach is the standard way to deal with
> > this?
> 
> I'd suggest we apply Vinson's patch and then build the codegen back-end
> with -std=c++0x (available on GCC 4.3 and later), otherwise GNU's
> libstdc++ will emit an error if you include any of the C++11 headers
> while building in C++98/03 mode.  -std=c++11 would work too but it's
> only supported since GCC 4.7.  Any reasonably recent Clang version (at
> least 2.9) should support both switches.

My concern is the boxes on which nouveau works fine but have older compilers (I'm thinking of RHEL or Ubuntu LTS style situations). I want those to work a lot more than I want nouveau to build on FreeBSD/OSX/whatever.

IIRC tr1 support came with GCC 4.0 or 4.1 or so, but I don't know which compilers came with which distros. I guess mesa already requires gcc 4.2 for something, so moving that up to 4.3 for nouveau may not be such a huge deal. I guess a patch which turns on -std=c++0x for codegen would be fine by me.

(In reply to Ilia Mirkin from comment #6)
> (In reply to Francisco Jerez from comment #5)
> > Most likely this bug is not caused by the Clang compiler itself, but by
> > the standard library implementation.  Apparently FreeBSD ships with
> 
> Yes, absolutely.
> 
> > LLVM's libc++ as default implementation these days, which implements the
> > C++11 standard library and doesn't attempt to support the TR1 namespace,
> > which is a C++03-specific extension.
> 
> OK. nouveau doesn't work on FreeBSD; any reason for me to care about it?
> 

*Shrug*, maybe not until the remainig bits are ported to FreeBSD.  In any case libc++ is nothing FreeBSD-specific, most major Linux distributions package it as well.

> > 
> > > If someone maps out the various version support for all this, perhaps we can
> > > make a decision. Or some other approach is the standard way to deal with
> > > this?
> > 
> > I'd suggest we apply Vinson's patch and then build the codegen back-end
> > with -std=c++0x (available on GCC 4.3 and later), otherwise GNU's
> > libstdc++ will emit an error if you include any of the C++11 headers
> > while building in C++98/03 mode.  -std=c++11 would work too but it's
> > only supported since GCC 4.7.  Any reasonably recent Clang version (at
> > least 2.9) should support both switches.
> 
> My concern is the boxes on which nouveau works fine but have older compilers
> (I'm thinking of RHEL or Ubuntu LTS style situations). I want those to work
> a lot more than I want nouveau to build on FreeBSD/OSX/whatever.
> 
> IIRC tr1 support came with GCC 4.0 or 4.1 or so, but I don't know which
> compilers came with which distros. I guess mesa already requires gcc 4.2 for
> something, so moving that up to 4.3 for nouveau may not be such a huge deal.
> I guess a patch which turns on -std=c++0x for codegen would be fine by me.

Maybe, I don't know if there's anyone left using GCC 4.2, and whether we should care.  GCC 4.3 happened almost 7 years ago, Ubuntu 10 LTS (the oldest release still supported by Canonical), RHEL 5 and 6 seem to be shipping GCC 4.4 already.

Created attachment 130208 [details] [review]
Proposed patch to support clang without too much hacking

Ilia,

May some patch like this works for it? Those 2 headers are the only ones breaking a correct clang compilation on the whole project since a long time. This should also work for old gcc compilers. For now I just tried with clang 4.0.0 and gcc 5.4.0. Currently there are LOT better ways to solve this issue, but because you want to support old GCC versions, this may be accurate. Is basically a hack over a hack.

This patch is based for mesa 17.0.1, but should also work for previous, I don't remember seeing those files being modified lately.

Lets just close this and worry about it if FreeBSD ever adds nouveau support.