According to the error message, "device.o" is the file that causes the error.
According to the source code to which you point, this file is
generated from a Cuda file, not from a C file. Cuda is close to C++,
and apparently nvcc makes use of C++ features. Thus you need the C++
run-time libraries.
"*.o" files do not automatically pull in libraries, only shared
libraries ("*.so") can do that.
-erik
On Sun, Mar 20, 2016 at 10:23 PM, Gilles Gouaillardet
<gilles.gouaillar...@gmail.com> wrote:
> I am a bit puzzled...
>
> if only cuda uses the c++ std libraries, then it should depend on them
> (ldd libcudaxyz.so can be used to confirm that)
> and then linking with cuda lib should pull the c++ libs
>
> could there be a version issue ?
> e.g. the missing symbol is not provided by the version of the c++ lib that
> is pulled.
> that might occur if you are using cuda built for distro X on distro Y
>
> could you please double check this ?
> if everything should work, then i recommend you report this to nvidia
>
> Cheers,
>
> Gilles
>
> On Monday, March 21, 2016, Damien Hocking <dam...@0x544745.com> wrote:
>>
>> Durga,
>>
>> The Cuda libraries use the C++ std libraries. That's the std::ios_base
>> errors.. You need the C++ linker to bring those in.
>>
>> Damien
>>
>> On March 20, 2016 9:15:47 AM "dpchoudh ." <dpcho...@gmail.com> wrote:
>>>
>>> Hello all
>>>
>>> I downloaded some code samples from here:
>>>
>>> https://github.com/parallel-forall/code-samples/
>>>
>>> and tried to build the subdirectory
>>>
>>> posts/cuda-aware-mpi-example/src
>>>
>>> in my CentOS 7 machine.
>>>
>>> I had to make several changes to the Makefile before it would build. The
>>> modified Makefile is attached (the make targets I am talking about are the
>>> 3rd and 4th from the bottom). Most of the modifications can be explained as
>>> possible platform specific variations (such as path differences betwen
>>> Ubuntu and CentOS), except the following:
>>>
>>> I had to use a C++ linker (mpic++) to link in the object files that were
>>> produced with C host compiler (mpicc) and CUDA compiler (nvcc). If I did not
>>> do this, (i.e. I stuck to mpicc for linking), I got the following link
>>> error:
>>>
>>> mpicc -L/usr/local/cuda/lib64 -lcudart -lm -o
>>> ../bin/jacobi_cuda_normal_mpi jacobi.o input.o host.o device.o
>>> cuda_normal_mpi.o
>>> device.o: In function `__static_initialization_and_destruction_0(int,
>>> int)':
>>> tmpxft_00004651_00000000-4_Device.cudafe1.cpp:(.text+0xd1e): undefined
>>> reference to `std::ios_base::Init::Init()'
>>> tmpxft_00004651_00000000-4_Device.cudafe1.cpp:(.text+0xd2d): undefined
>>> reference to `std::ios_base::Init::~Init()'
>>> collect2: error: ld returned 1 exit status
>>>
>>> Can someone please explain why would I need a C++ linker for object files
>>> that were generated using C compiler? Note that if I use mpic++ both for
>>> compiling and linking, there are no errors either.
>>>
>>> Thanks in advance
>>> Durga
>>>
>>> Life is complex. It has real and imaginary parts.
>>> _______________________________________________
>>> users mailing list
>>> us...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/users/2016/03/28760.php
>
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/03/28762.php
--
Erik Schnetter <schnet...@gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/
