> On Mar 19, 2018, at 2:51 PM, Jed Brown <j...@jedbrown.org> wrote: > > Satish Balay <ba...@mcs.anl.gov> writes: > >> On Mon, 19 Mar 2018, Jed Brown wrote: >> >>> Satish Balay <ba...@mcs.anl.gov> writes: >>> >>>> On Mon, 19 Mar 2018, Satish Balay wrote: >>>> >>>>> On Mon, 19 Mar 2018, Jed Brown wrote: >>>>> >>>>>> Satish Balay <ba...@mcs.anl.gov> writes: >>>>>> >>>>>>>> Thanks for the diagnosis. Can we use @rpath/libpetsc.3.08.dylib? Then >>>>>>>> we wouldn't need to run install_name_tool either. If we want the >>>>>>>> absolute path written into the dylib, I can do that. >>>>>>> >>>>>>> You mean '-install_name ${PREFIXDIR}/lib/libpetsc.3.08.dylib'? Yes - >>>>>>> this should eliminate the need for install_name_tool in 'make install' >>>>>>> [and that code can be removed] >>>>>> >>>>>> No, I mean -install_name @rpath/libpetsc.3.08.dylib. >>>>> >>>>> >>>>> mpicc -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress >>>>> -Wl,-commons,use_dylibs -Wl,-search_paths_first -Wl,-no_compact_unwind >>>>> -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas >>>>> -fstack-protector -Qunused-arguments -fvisibility=hidden -g3 -dynamiclib >>>>> -install_name -install_name @rpath/libpetsc.3.08.dylib >>>>> -compatibility_version 3.08 -current_version 3.08.3 -single_module >>>>> -multiply_defined suppress -undefined dynamic_lookup -o >>>>> arch-prefix/lib/libpetsc.3.08.3.dylib ... >>>>> <snip> >>>>> clang: error: no such file or directory: '@rpath/libpetsc.3.08.dylib' >>>>> make[2]: *** [arch-prefix/lib/libpetsc.3.08.3.dylib] Error 1 >>>> >>>> Ops - I have -install_name option listed twice. >>>> >>>> removing the dupliate.. >>>> >>>> balay@ipro^~/petsc(next) $ make PETSC_DIR=/Users/balay/pinstall >>>> PETSC_ARCH="" test >>>> Running test examples to verify correct installation >>>> Using PETSC_DIR=/Users/balay/pinstall and PETSC_ARCH= >>>> C/C++ example src/snes/examples/tutorials/ex19 run successfully with 1 MPI >>>> process >>>> C/C++ example src/snes/examples/tutorials/ex19 run successfully with 2 MPI >>>> processes >>>> Fortran example src/snes/examples/tutorials/ex5f run successfully with 1 >>>> MPI process >>>> Completed test examples >>>> ========================================= >>>> Now to evaluate the computer systems you plan use - do: >>>> make PETSC_DIR=/Users/balay/pinstall PETSC_ARCH= streams >>>> balay@ipro^~/petsc(next) $ >>>> balay@ipro^~/petsc(next) $ otool -L ~/pinstall/lib/libpetsc.dylib >>>> /Users/balay/pinstall/lib/libpetsc.dylib: >>>> @rpath/libpetsc.3.08.dylib (compatibility version 3.8.0, current >>>> version 3.8.3) >>>> >>>> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib >>>> (compatibility version 1.0.0, current version 1.0.0) >>>> >>>> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib >>>> (compatibility version 1.0.0, current version 1.0.0) >>>> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version >>>> 400.9.0) >>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>>> version 1252.0.0) >>>> /Users/balay/soft/mpich-3.2/lib/libmpifort.12.dylib (compatibility >>>> version 14.0.0, current version 14.0.0) >>>> /Users/balay/soft/mpich-3.2/lib/libmpi.12.dylib (compatibility version >>>> 14.0.0, current version 14.0.0) >>>> /Users/balay/soft/mpich-3.2/lib/libpmpi.12.dylib (compatibility version >>>> 14.0.0, current version 14.0.0) >>>> /usr/local/opt/gcc/lib/gcc/7/libgfortran.4.dylib (compatibility version >>>> 5.0.0, current version 5.0.0) >>>> /usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, >>>> current version 1.0.0) >>>> /usr/local/opt/gcc/lib/gcc/7/libquadmath.0.dylib (compatibility version >>>> 1.0.0, current version 1.0.0) >>>> /Users/balay/soft/mpich-3.2/lib/libmpicxx.12.dylib (compatibility >>>> version 14.0.0, current version 14.0.0) >>>> >>>> >>>> Ok - this works.. >>> >>> The consequence here is that users would be expected to use -Wl,-rpath, >>> when linking to libpetsc.dylib, where now they probably get away without >>> (on OSX). >> >> Using '-install_name ${PREFIXDIR}/lib/libpetsc.3.08.dylib' would keep the >> current behavior. > > Right, but that would prevent it from working in the build directory.
I could care less about it working from the build directory. We don't test there anyways. Barry > If you want both, you either need to relink or run install_name_tool as > we currently do. With @rpath, you don't need any of that. There are > arguments in favor of either convention.