Bug report - compilation error

I am running into a compilation error with CUDA 2.1 beta on Ubuntu 8.04 using g++ 4.2.4. The following is a minimal test case (yes, just one include, no other code):

#include <fstream>

When I try to compile this, I get:

nvcc -c testcase.cu

/usr/include/c++/4.2/bits/ios_base.h:408: error: declaration of ‘typedef class std::streampos std::ios_base::streampos’

/usr/include/c++/4.2/bits/postypes.h:211: error: changes meaning of ‘streampos’ from ‘typedef class std::fpos<__mbstate_t> std::streampos’

/usr/include/c++/4.2/bits/ios_base.h:409: error: declaration of ‘typedef std::streamoff std::ios_base::streamoff’

/usr/include/c++/4.2/bits/postypes.h:72: error: changes meaning of ‘streamoff’ from ‘typedef int64_t std::streamoff’

The only other mention of this problem I found is http://www.c-plusplus.de/forum/viewtopic-v…-is-228781.html (in German), which provides no solution.

This bug is fairly annoying as I use a lot in my code and now cannot combine it with CUDA.

Edit: Reduced the test case to a single line.

Edit 2: As reported on IRC, this is fixed in 2.1 final.

regarding your Edit 2: this will be fixed in the 2.2 release, not in the 2.1 final.

regretfully, there’s no workaround for it though.

Brilliant.

Should anyone else run into this, here is a workaround that works for me (using 2.1 beta). I modeled this after CUDA 2.0 but of course I cannot guarantee it won’t break something in 2.1…

--- math_functions.h.orig	   2008-12-18 14:36:21.000000000 +0000

+++ math_functions.h	2008-12-18 14:39:41.000000000 +0000

@@ -471,6 +471,7 @@

   template<typename T> extern __host__ __device__ T __cmath_power(T, unsigned int);

 }

+using namespace std;

 using std::abs;

 using std::fabs;

 using std::ceil;

this could very well work.
this particular bug is related to the std namepsace.

adding a using statement in your sourcefile, before including iostram would work as well then
and this would leave the cuda geadrfiles untouched

Cool, two different workarounds then exist. I personally prefer to add a hack where the bug is (i.e. in CUDA, not in my source) but changing the source may be less intrusive in some cases I guess.

This fixed the problem for me. Thanks!