Opened 5 years ago

Last modified 5 years ago

#1636 new feature

Preserve LD_RUN_PATH environment variable in compiler wrappers

Reported by: valdes Owned by:
Priority: minor Milestone: future
Component: mpich Keywords:
Cc:

Description (last modified by balaji)

When MPICH2 is built with shared libraries enabled, the various mpi compiler wrappers (mpicc, mpif77, etc) will add the -rpath option (or other OS equivalent) with the path to the directory containing the MPICH2 libraries to the command line it uses to invoke the underlying compiler. That's a good thing, since that embeds the path to the MPICH shared libraries in the executable, making them easier to find at runtime. However, most linkers that support an -rpath like option will then ignore paths given via an environment variable (eg LD_RUN_PATH) if the -rpath is specified. The result is that if one is compiling an MPI application that is dependent on multiple shared libraries (eg, HDF5, Intel MKL, etc), and the (runtime) path to the other libraries is specified via an environment variable (LD_RUN_PATH), then the -rpath option added by the mpi compiler wrappers will override the environment variable, and the path to the other libraries won't be saved in the resulting executable.

I propose that the mpi compiler wrappers "preserve" the setting of LD_RUN_PATH (or equivalent) by appending its value to the MPICH library path passed to the -rpath option. GNU ld (used by linux and sadly most/all *BSD these days) and Solaris ld support a colon-separated list of directories after the -rpath/-R option and both use LD_RUN_PATH as the environment variable for specifying runtime directories in the absence of the -rpath/-R option, so appending the value of ":$LD_RUN_PATH" should do the trick (or more cleanly, appending "${LD_RUN_PATH:+:}$LD_RUN_PATH" so that the colon is added only if $LD_RUN_PATH is defined and non-null). Attached is a suggested patch that does this for the 4 compiler wrappers that should work on any system that uses LD_RUN_PATH (pretty much all unix supported by MPICH, I think, except OS X; don't know what the latter uses, if anything).

Attachments (1)

ld_run_path.patch (1.7 KB) - added by valdes 5 years ago.
patch to preserve LD_RUN_PATH in compiler wrappers

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by valdes

patch to preserve LD_RUN_PATH in compiler wrappers

comment:1 Changed 5 years ago by goodell

  • Description modified (diff)

(reformat for trac)

comment:2 Changed 5 years ago by goodell

The patch is missing corresponding changes to mpicc.bash.in and friends.

I think that DYLD_LIBRARY_PATH on Darwin is equivalent to LD_LIBRARY_PATH on Linux, but I don't think there is any Darwin equivalent for LD_RUN_PATH.

I'm not sure how I feel about this patch. I would prefer to avoid determining whether LD_RUN_PATH works on the current platform. Is your use case suitably handled by passing --disable-wrapper-rpath (for releases >= 1.5a1) or --disable-rpath (for releases <= 1.4.1p1)? In that case the linker should automatically respect the LD_RUN_PATH in the environment, you just need to make sure that it also includes the MPICH2 $(libdir).

comment:3 Changed 5 years ago by balaji

  • Milestone set to future
  • Owner set to goodell
  • Status changed from new to assigned

comment:4 Changed 5 years ago by balaji

  • Description modified (diff)
  • Owner goodell deleted
  • Status changed from assigned to new
Note: See TracTickets for help on using tickets.