[petsc-dev] Tests are not working for me in next

[Smith, Barry F.]

> On Mar 19, 2018, at 2:51 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Satish Balay <balay at mcs.anl.gov> writes:
> 
>> On Mon, 19 Mar 2018, Jed Brown wrote:
>> 
>>> Satish Balay <balay at mcs.anl.gov> writes:
>>> 
>>>> On Mon, 19 Mar 2018, Satish Balay wrote:
>>>> 
>>>>> On Mon, 19 Mar 2018, Jed Brown wrote:
>>>>> 
>>>>>> Satish Balay <balay at 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 at 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 at ipro^~/petsc(next) $ 
>>>> balay at 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.