Hi,
I am having difficulties compiling the sdk. Specifically, when I attempt a make I get the following errors:
[codebox]make[1]: Entering directory `/home/userid/NVIDIA_CUDA_SDK/projects/histogram256’
/usr/include/bits/stdio2.h(35): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(66): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(99): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(105): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(159): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(167): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(174): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(182): error: identifier “__builtin_va_arg_pack” is undefined
8 errors detected in the compilation of “/tmp/tmpxft_00006092_00000000-4_histogram256_SM10.cpp1.ii”.
make[1]: *** [obj/release/histogram256_SM10.cu_sm_10.o] Error 255
make[1]: Leaving directory `/home/userid/NVIDIA_CUDA_SDK/projects/histogram256’
make: *** [projects/histogram256/Makefile.ph_build] Error 2
[/codebox]
Details of the machine:
Kubuntu 8.10 64bit
gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2
2x 8800M GT
I’ve noticed several others have had the same issue, but I have not seen a solution to this problem.
Any ideas?
Thanks!
Hi,
I am having difficulties compiling the sdk. Specifically, when I attempt a make I get the following errors:
[codebox]make[1]: Entering directory `/home/userid/NVIDIA_CUDA_SDK/projects/histogram256’
/usr/include/bits/stdio2.h(35): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(66): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(99): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(105): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(159): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(167): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(174): error: identifier “__builtin_va_arg_pack” is undefined
/usr/include/bits/stdio2.h(182): error: identifier “__builtin_va_arg_pack” is undefined
8 errors detected in the compilation of “/tmp/tmpxft_00006092_00000000-4_histogram256_SM10.cpp1.ii”.
make[1]: *** [obj/release/histogram256_SM10.cu_sm_10.o] Error 255
make[1]: Leaving directory `/home/userid/NVIDIA_CUDA_SDK/projects/histogram256’
make: *** [projects/histogram256/Makefile.ph_build] Error 2
[/codebox]
Details of the machine:
Kubuntu 8.10 64bit
gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2
2x 8800M GT
I’ve noticed several others have had the same issue, but I have not seen a solution to this problem.
Any ideas?
Thanks!
I believe that this is a known bug in the gcc that ships with Ubuntu-8.10. As Ubuntu-8.10 isn’t currently supported, there is no current workaround that I’m aware of. It will be worked around in nvcc (and friends) in the next CUDA release, when Ubuntu-8.10 will be formally supported.
I believe that this is a known bug in the gcc that ships with Ubuntu-8.10. As Ubuntu-8.10 isn’t currently supported, there is no current workaround that I’m aware of. It will be worked around in nvcc (and friends) in the next CUDA release, when Ubuntu-8.10 will be formally supported.
Thank you for your response. Any idea as to when support for 8.10 will arrive?
A second question, I did manage to get things compiling (after removing the -O3 flag), however when I attempt to run deviceQuery, I get the following
error:
cudaSafeCall() Runtime API error in file <deviceQuery.cu>, line 59 : invalid argument.
I know that 8.10 is not supported, however I wonder what the meaning of this error is (perhaps this error is not a result of no 8.10 support).
I made some changes to deviceQuery’s code, and was able to determine that “cudaGetDeviceProperties(&deviceProp, dev);”
returns error code 11. And when I attempt to read the device name, I get a string of 4 nonsense characters (funky question mark symbols from the
extended ascii set). However it was able to determine that I had 2 devices.
Any thoughts?
Thanks for the help!
I believe that this is a known bug in the gcc that ships with Ubuntu-8.10. As Ubuntu-8.10 isn’t currently supported, there is no current workaround that I’m aware of. It will be worked around in nvcc (and friends) in the next CUDA release, when Ubuntu-8.10 will be formally supported.
I have found a workaround on my install of intrepid:
[codebox]$ sudo apt-get install gcc-4.2 g+±4.2
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.2 60 --slave /usr/bin/g++ g++ /usr/bin/g+±4.2[/codebox]
This basically rolls back to using GCC 4.2.
mv1
February 12, 2009, 12:16pm
5
I just tried compiling the SDK on a new build with RHEL 5.3 64-bit and got the following errors:
In file included from ParticleSystem.cu:42:
ParticleSystem.cuh:22:2: warning: no newline at end of file
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(380): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
./new_radixsort.cu(1047): Advisory: Removed dead synchronization intrinsic
/usr/bin/ld: cannot find -lglut
collect2: ld returned 1 exit status
make[1]: *** […/…/bin/linux/release/smokeParticles] Error 1
make[1]: Leaving directory `/root/NVIDIA_CUDA_SDK/projects/smokeParticles’
make: *** [projects/smokeParticles/Makefile.ph_build] Error 2
[root@localhost NVIDIA_CUDA_SDK]#
[root@localhost NVIDIA_CUDA_SDK]#
[root@localhost NVIDIA_CUDA_SDK]# echo $LD_LIBRARY_PATH
:/usr/local/cuda/lib
[root@localhost NVIDIA_CUDA_SDK]# echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin:/usr/local/cuda/bin
Would appreciate help to fix the above.
Thank you!
You need to install the glut libraries. You can search the forums for the exact name, I think it is called libGL-devel, but am not sure.
RHEL 5.3 is not supported btw, so you can encounter more trouble (that might be unsolvable). There are 2 options if I understand good:
install RHEL 5.2
downgrade GCC.
tmurray
February 12, 2009, 8:21pm
7
RHEL 5.3 works fine, it’s still an older compiler:
[root@localhost /]# gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root@localhost /]# uname -r
2.6.18-128.el5
aka, that’s RHEL 5.3 I’m running at this very second (and I’ve got Ubuntu 8.10 on another machine! netllama probably thinks I’m a horrible person)
so not officially supported at the moment, but I’ve yet to encounter any meaningful problems
mv1
February 13, 2009, 1:33am
8
RHEL 5.3 works fine, it’s still an older compiler:
[root@localhost /]# gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root@localhost /]# uname -r
2.6.18-128.el5
aka, that’s RHEL 5.3 I’m running at this very second (and I’ve got Ubuntu 8.10 on another machine! netllama probably thinks I’m a horrible person)
so not officially supported at the moment, but I’ve yet to encounter any meaningful problems
When will it be supported officially?
Hopefully very soon.
What kinds of meaningless problems have you encountered?
So, what shall I do?
Downgrade to RHEL 5.2 or go ahead with 5.3?
tmurray
February 13, 2009, 6:18am
9
Up to you–it will be supported at Some Point (I don’t presume to speak for the driver or toolkit teams), but that will affect future releases only.
HankD
February 27, 2009, 6:45pm
10
I have found a workaround on my install of intrepid:
[codebox]$ sudo apt-get install gcc-4.2 g+±4.2
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.2 60 --slave /usr/bin/g++ g++ /usr/bin/g+±4.2[/codebox]
This basically rolls back to using GCC 4.2.
Going back to 4.2 isn’t necessary. This problem comes down to a little piece of
[codebox]/usr/include/sys/cdefs.h[/codebox]
that defines the builtin versions only if it’s 4.3. I simply took those defs out and
everything apparently works fine. The stuff to disable is:
[codebox]#if __GNUC_PREREQ (4,3)
define __va_arg_pack() __builtin_va_arg_pack ()
define __va_arg_pack_len() __builtin_va_arg_pack_len ()
endif [/codebox]
Yeah, I know editing such files is bad, but it works without going back to GCC 4.2.
Going back to 4.2 isn’t necessary. This problem comes down to a little piece of
[codebox]/usr/include/sys/cdefs.h[/codebox]
that defines the builtin versions only if it’s 4.3. I simply took those defs out and
everything apparently works fine. The stuff to disable is:
[codebox]#if __GNUC_PREREQ (4,3)
define __va_arg_pack() __builtin_va_arg_pack ()
define __va_arg_pack_len() __builtin_va_arg_pack_len ()
endif [/codebox]
Yeah, I know editing such files is bad, but it works without going back to GCC 4.2.
Thanks, it seems to work now. I could not solve the problem by reverting to 4.2 (I edited the example’s Makefile to use g+±4.2 and gcc-4.2 and it gave the same error), what worked was removing the optimization -03 altogether. Removing the optimizations is bad for me, as long as cdefs.h does not break anything it would work for me.