Am Fri, 01 Aug 2014 09:43:27 -0500 schrieb Jason Bacon <jwbacon%tds.net@localhost>: > I attached our build script from the old RHEL 5.3 installation. No > guarantees that it will solve your issue, but we didn't have any such > issues on that system. Well, yes I see baking in of rpaths there. It occured to me that a "proper" compiler installation probably means to hardcode the rpath in the gcc spec file. The other obvious solution is wrapper script over gcc/g++/gfortran that either adds linker flags or prepends to $LD_RUN_PATH. The wrapper script is actually a solution recommended on https://gcc.gnu.org/faq.html#rpath . For our purposes it would have to be a smart wrapper script since we'd like to support the LD_RUN_PATH use-case (which is destroyed by the first -rpath entering the scene). But frankly, things are so twisted with specific software (for example the Intel compiler linking in its OpenMP runtime lib with full path in a plain build with `ifort -openmp`, but forgetting the path when building with `mpifort -openmp` for a program using OpenMP and MPI), that the overall solution for unaware users (of the compilers) is setting of LD_LIBRARY_PATH. We set that in our shell environment module files to ensure stuff is found either way. For binaries we as admins produce for the users, we'll keep carefully tuning necessary rpath flags or LD_RUN_PATH (not with pkgsrc, obviously) to yield binaries that don't require any special environment to function. But since HPC users are often building software just for themselves to run, it is rather hard requirement to have them figure out how to properly link things with rpath to make robust binaries in the multitude of possible system environments. Wrapper scripts over the compilers may help, but it's another source of complexity that we need to maintain. All in all, this sucks --- and it's not just GCC (see Intel example above)! Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Zentrale Dienste / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270
Attachment:
smime.p7s
Description: S/MIME cryptographic signature