Defect: install.sh should tell users to set DYLD_LIBRARY_PATH not LD_LIBRARY_PATH on macOS

[zbeekman]

Avg response time

Defect/Bug Report

See #562 for context. Thanks to @dtabell for bringing this to our attention.

• OpenCoarrays Version: All known version to date
• Fortran Compiler: GFortran 8.1 and previous
• C compiler used for building lib: GCC (but same issue for clang etc.)
• Installation method: install.sh
• Output of uname -a: all macOS machines
• MPI library being used: MPICH & OpenMPI affected
• Machine architecture and number of physical cores: All
• Version of CMake: Latest in install.sh but CMake version irrelavent

Observed Behavior

install.sh instructs the user to set LD_LIBRARY_PATH no matter what the OS, but this should be DYLD_LIBRARY_PATH on macOS. Under some circumstances, particularly for advanced users (who should probably realize this to begin with...) or other users who install all/most pre-requisites with install.sh on macOS it might be possible that runtime errors are encountered if dylibs are linked in that have been installed to non-standard locations.

Expected Behavior

Correct instructions/environment settings on macOS

Steps to Reproduce

Install OpenCoarrays with install.sh and read the text & file to be sourced at the end.

[dtabell]

When you get to the point of modifying the setup.sh script, there are two other small issues you might consider addressing:

• The stanza that prepends the cmake path to $PATH stands a good chance of being redundant. Should one test to see if that location already exists in $PATH?

• In that same stanza, delete the trailing slash currently added to the cmake path. This is not a bug fix, but an aesthetic fix: which cmake now returns (for me) /usr/local/bin//cmake instead of /usr/local/bin/cmake.

[zbeekman]

@rouson I think we need to re-confirm and re-verify our use of LD_LIBRARY_PATH (and DYLD_LIBRARY_PATH). Both throughout the install scripts, and in the advice to users. Two packages that may require it are GFortran (less likely) and MPICH (likely). I've encountered tons of bugs that were a real pain to sort out because of LD_LIBRARY_PATH and common consensus (across the internet at least) is that setting these variables usually cause more harm than good. I'm nervous about implementing this RFE/bug-fix because I do not want to encourage users to be setting these variables.

[zbeekman]

OK, upon further review of the current code, I think that it makes sense to keep this. It is only set for the compiler, not for anything else, and presumably, it was set through experience on Linux. I'm not convinced we need it on macOS, but I don't have the time or energy to investigate, so I'll update the variable based on the OS per Dan's suggestion.