[CMake] NVCC and Shared Library Full Path Linking

[Brad King]

On 12/16/2013 04:25 PM, MARTIN, ROBERT S CTR USAF AFMC AFRL/RQRS wrote:
> Nvlink fatal   : Unsupported file type '/usr/lib/openmpi/lib/libmpi_cxx.so'
> 
> If I replace the '/usr/lib/openmpi/lib/libmpi_cxx.so' with
> '-L/usr/lib/openmpi/lib/ -lmpi_cxx', it works.  When I look at the ldd
> output, it's even correctly still linking to the .so (rather than a static
> library).  Interestingly enough, on a different machine with a similar setup
> the FindMPI module adds the '-L -l' options instead of the full path (mpich
> instead of openmpi though?).

Prior to CMake 2.6, CMake always split /path/to/libfoo.so into -L/path/to -lfoo.
We had no end of problems with choosing the correct shared/static library,
conflicts of ordering of the -L paths needed for different libraries, etc.
Starting with CMake 2.6 we always use full paths to tell the linker exactly
what file to use.  The only exception is explained here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8795/focus=8812

where libraries in implicit linker search paths get converted to "-lfoo"
(which could be the case on your other machine).  Most complaints we've
had about the current behavior have been about this exception when the user
wants a full path.  The IMPORTED target approach can be used for that case.

> Is this currently an encouraged approach?  Is there a way to control the
> behavior in cmake to force CMake to choose using '-L/-l' instead of full
> paths?

If you just want to achieve it locally for your own build then you can
change the cache entry that currently holds the full path to the library
to name just the library (mpi_cxx) and add the -L flag to the
CMAKE_EXE_LINKER_FLAGS.  To do it in project code for general use
you'll need to process and split the library with get_filename_component.

> I realize this could also be considered more of a bug with nvlink

Yes, I've never seen a linker that can't handle full paths to library files.

-Brad