Bug 88766 - codegen/nv50_ir.h:585:9: error: no member named 'tr1' in namespace 'std'
Summary: codegen/nv50_ir.h:585:9: error: no member named 'tr1' in namespace 'std'
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: x86-64 (AMD64) FreeBSD
: medium blocker
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-24 03:49 UTC by Vinson Lee
Modified: 2019-05-07 02:41 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Remove tr1 namespace. (5.14 KB, patch)
2015-01-24 04:46 UTC, Vinson Lee
Details | Splinter Review
Proposed patch to support clang without too much hacking (1.38 KB, patch)
2017-03-14 06:44 UTC, Pablo Cholaky
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2015-01-24 03:49:18 UTC
mesa: 94e7b59a75fc2ecc51a74196f6cd198546603b85 (master 10.5.0-devel)

Build error on FreeBSD.

  CXX      codegen/nv50_ir.lo
In file included from codegen/nv50_ir.cpp:23:
./codegen/nv50_ir.h:585:9: error: no member named 'tr1' in namespace 'std'
   std::tr1::unordered_set<ValueRef *> uses;
   ~~~~~^
Comment 1 Ilia Mirkin 2015-01-24 04:29:57 UTC
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.
Comment 2 Vinson Lee 2015-01-24 04:40:42 UTC
The error was seen on FreeBSD 10 with clang 3.4.

Removing the tr1 namespace fixes the build errors.
Comment 3 Vinson Lee 2015-01-24 04:46:48 UTC
Created attachment 112757 [details] [review]
Remove tr1 namespace.
Comment 4 Ilia Mirkin 2015-01-24 04:59:20 UTC
(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?
Comment 5 Francisco Jerez 2015-01-24 13:22:02 UTC
(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.
Comment 6 Ilia Mirkin 2015-01-24 21:59:20 UTC
(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.
Comment 7 Francisco Jerez 2015-01-25 13:24:13 UTC
(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.
Comment 8 Pablo Cholaky 2017-03-14 06:44:46 UTC
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.
Comment 9 Timothy Arceri 2019-05-07 02:41:39 UTC
Lets just close this and worry about it if FreeBSD ever adds nouveau support.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.