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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to