> On Aug 22, 2016, at 1:19 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
> Hi Jim:
> 
> You said:
> 
>> I ran the comprehensive test suite [presumably for test_fortran] and got the 
>> following error
> 
>> ERROR: cmake in the build tree failed
> 
>> I reran the test and specified the fortran compiler and got the test
> to run (see attached tarball)
> 
> Thanks very much for that.  Your comprehensive test of the
> test_fortran project indeed seems to work, but I have further
> questions about what goes on with the Mac OS X rpath manipulations,
> and if you don't have the Mac OS X linking experience to answer those,
> I hope someone else from this list does.
> 
> Here is what is bothering me about the Mac OS X rpath manipulations.
> 
> Specifically (see
> shared/noninteractive/output_tree/make_noninteractive.out) in the
> build tree, the library build is done using
> 
> /opt/local/bin/gfortran-mp-5   -dynamiclib -Wl,-headerpad_max_install_names  
> -o libhello.0.0.dylib -install_name @rpath/libhello.0.dylib 
> CMakeFiles/hello_1.dir/hello_1.f90.o

Per the Apple documentation 
(https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html)
 the @rpath is used to create a run-path dependent library.

> 
> and the executable build is done using
> 
> /opt/local/bin/gfortran-mp-5     CMakeFiles/hello.dir/hello.f90.o  -o hello  
> ../src_lib/libhello.0.0.dylib 
> -Wl,-rpath,/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib
> 

In this case gfortran is invoking ld, which will resolve the run-path.  Because 
the rpath is specified with an absolute path name, the executable will be have 
absolute paths to the dynamic libraries.  One can have a path search if 
“@loader_path” is used.

> 
> 
> In the install tree (see
> shared/noninteractive/output_tree/make_noninteractive.out) the Mac OS X and 
> Linux equivalent
> commands for building the installed executable are
> 
> /opt/local/bin/gfortran-mp-5  CMakeFiles/hello.dir/hello.f90.o  -o hello  
> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib
> 

Looking at the output from otool, the paths to libhello is the absolute.  
Looking at the Apple documentation, it appears that ld will use use the 
absolute path name if @rpath is not specified.

Relevant output from otool 

Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 152
         name 
/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.dylib
 (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 0.0.0
compatibility version 0.0.0
Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 72
         name /opt/local/lib/libgcc/libgfortran.3.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 4.0.0
compatibility version 4.0.0
Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1226.10.1
compatibility version 1.0.0
Load command 15
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /opt/local/lib/libgcc/libgcc_s.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.0.0
compatibility version 1.0.0
Load command 16
          cmd LC_LOAD_DYLIB
      cmdsize 72
         name /opt/local/lib/libgcc/libquadmath.0.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.0.0
compatibility version 1.0.0

> Here we have used (with the patched version of test_fortran and
> test_ada) the same installed rpath manipulations for both Mac OS X and
> Linux which (following what works for PLplot and Linux) are simply to
> set the INSTALL_RPATH property of the library to the install location
> of that library but say nothing at all about the rpath of the
> executable (see cmake/test_fortran/src_lib/CMakeLists.txt and
> cmake/test_fortran/src_executable/CMakeLists.txt).  As
> you can see above, the result is rpath is set properly for the build
> of the executable in the install tree for the Linux case, but there is
> _no_ rpath manipulation at all for that executable in the Mac OS X case.
> 
> Nevertheless, the result for both Mac OS X and Linux is the run-time loader 
> finds
> the library and executes the hello executable in the install tree
> without issues, but for the Mac OS X case, I don't see how that is
> possible since rpath has obviously not been set.
> 

The lack rpath manipulation is not needed, though it results in an executable 
that will not run if the
library is moved.  If I remove or move libhello, the executable fails to load: 

dyld: Library not loaded: 
/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.dylib
  Referenced from: 
/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/./install_build_tree/fortran/hello
  Reason: image not found
Trace/BPT trap: 5

> Can you (or someone else here with Mac OS X linking expertise) help me
> figure out what is going on here?  The first step in that investigation 
> (after the
> comprehensive test is completed) is you should be able to go
> to the installed location of the hello executable (in your case that would be
> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_build_tree/fortran)
> and execute ./hello there without setting DYLD_LIBRARY_PATH.  If that
> works (and I assume it will from your comprehensive test results done
> without setting DYLD_LIBRARY_PATH), then how does the run-time loader
> know the location of the installed library which in your case is
> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib?
> From past interactions with Mac OS X users, my understanding is you
> can find the answer to the above questions with tool.

It works fine and I do not have DYLD_LIBRARY_PATH set.  

For PLplot, there are several options on how to proceed for Mac OS X.  From 
what I can tell, it is possible to mimic the Linux behavior.  There is a 
discussion on the CMake site (https://cmake.org/Wiki/CMake_RPATH_handling) that 
might help with the configuration. 



------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to