Incorrect setting for caf_lib_dir in Installed caf script

[nncarlson]

Using a cmake installation prefix in /opt/..., I found that the installed caf script sets caf_lib_dir=lib64 which is incorrect. It should have been prefixed by the value of CMAKE_INSTALL_PREFIX. You're getting the value from CMAKE_INSTALL_LIBDIR which is set by the GNUInstallDirs module, and it isn't always an absolute path. I think maybe you want CMAKE_INSTALL_FULL_LIBDIR here.

Same issue for caf_mod_dir, but that was irrelevant in my case.

I think this is likely related to some of the issues from #268.

[zbeekman]

Many thanks! Yes you're right. I think in most places I need to carefully examine the usage and ensure we have full paths where needed. I'll get to this ASAP

[zbeekman]

@nncarlson just curious did you set the prefix at CMake/configure time or build/make time? I'm wondering if I might need to do something clever to treat the case where the user changes the installation location after they have configured with CMake, on the command line to make...

[nncarlson]

@zbeekman on the cmake command line. Often wondered if the cmake-generated makefiles are designed to allow it to be changed on the the make command line as they are with autoconf.

[zbeekman]

I think it may depend on the implementation and whether or not they accounted for it... the short answer, is: theoretically, yes, and theoretically it *should* be taken care of accurately... it should be possible, and a correct implementation *should* account for it. But the problem is it's complicated... IMO CMake is like git, it's the worst possible option, except for all the alternatives.

…

On Sat, Jan 28, 2017 at 6:54 PM Neil Carlson ***@***.***> wrote: @zbeekman <https://github.com/zbeekman> on the cmake command line. Often wondered if the cmake-generated makefiles are designed to allow it to be changed on the the make command line as they are with autoconf. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#321 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAREPAr-A96QjVLvYzIUb7UANb3e1fGvks5rW9UwgaJpZM4LwkE7> .

[jerryd]

Not sure if this is related but on my multi-lib system (both lib and lib64) we seem to be installing in lib and not lib64 even though default compilation is 64-bit. (linux fedora 25). In this case we should consider building for both cases, but the libcaf-mpi.a should be placed in lib64

[jerryd]

Example, I have LD_LIBRARY_PATH pointing to lib and lib64:

[jerry@amda8 coarrayHelloWorld]$ caf hello_multiverse.F90 
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libgfortran.so when searching for -lgfortran
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libgfortran.a when searching for -lgfortran
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libquadmath.so when searching for -lquadmath
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libquadmath.a when searching for -lquadmath
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /home/jerry/dev/usr/lib/libgcc_s.so.1 when searching for libgcc_s.so.1

[jerry@amda8 coarrayHelloWorld]$ cafrun  ./a.out 

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   PID 13107 RUNNING AT amda8.localdomain
=   EXIT CODE: 139
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions

[zbeekman]

I'll look into the CMake way of building both 32 and 64bit libs. Should we build shared/dynamic libs and static? Do we need 32 and 64 there as well?

[zbeekman]

@jerryd just saw your comment

Example, I have LD_LIBRARY_PATH pointing to lib and lib64

So are the errors you're seeing because it's in /lib and not lib64?

[nncarlson]

@jerryd, that's odd I'm also on Fedora 25 64-bit, but mine was installed in lib64. However, GNUInstallDirs does some special things for specific cases of cmake_install_prefix

[jerryd]

Tells me I have something broken, so will start clean and report back.