mmizzle9 / cudpp

Automatically exported from code.google.com/p/cudpp
Other
0 stars 0 forks source link

Linking against cudart 32bit on 64 bit environment #54

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
This happened while compiling simpleCUDPP example.

$ make
/usr/bin/ld: skipping incompatible /usr/local/cuda/lib/libcudart.so when
searching for -lcudart
/usr/bin/ld: skipping incompatible /usr/local/cuda/lib/libcudart.so when
searching for -lcudart
/usr/bin/ld: cannot find -lcudart
collect2: ld returned 1 exit status
make: *** [../../bin/linux/release/simpleCUDPP] Errore 1

Simple bugfix:
Change line 229 of linux_build/common.mk to
LIB       := -L$(CUDA_INSTALL_PATH)/lib64 -L$(LIBDIR) -L$(COMMONDIR)/lib
-lcuda -lcudart ${OPENGLLIB} $(PARAMGLLIB) $(CUDPPLIB) ${LIB}

Or, better, check if the arch is 64bit and link against the correct version

Original issue reported on code.google.com by condel...@gmail.com on 2 May 2010 at 8:09

GoogleCodeExporter commented 8 years ago
Oh, i forgot one thing.

This happened on cudpp-1.1.1

Original comment by condel...@gmail.com on 2 May 2010 at 8:10

GoogleCodeExporter commented 8 years ago
On a machine here, the CUDA installer seems to have created a soft link called 
"lib" 
which points to lib64.  Therefore this problem doesn't reproduce.

I'm am trying to decide whether I need to fix this or if I can rely on that 
soft link 
being there.

Original comment by harr...@gmail.com on 13 May 2010 at 12:32

GoogleCodeExporter commented 8 years ago
Well, it shouldn't be hard to decide whether the environment is 32bit or 64bit 
and if
we are cross-compiling.

Original comment by condel...@gmail.com on 13 May 2010 at 8:23

GoogleCodeExporter commented 8 years ago
On my machine, the CUDA installer has created both lib and lib64, containing 
different files (presumably it has created 32 and 64 bit libraries).

Therefore the issue did exist for me (and I could not create the soft-link in 
order to bypass it).

Having just checked out the latest version from the SVN (post-1.1.1), it works 
fine - thanks!

Original comment by nbur...@gmail.com on 21 Jun 2010 at 1:58

GoogleCodeExporter commented 8 years ago
This should be fixed by r136.  nburles seems to confirm it, but we should 
confirm for sure before marking verified.

Original comment by harr...@gmail.com on 21 Jun 2010 at 9:05