On 2016-08-23 21:29-0400 Jim Dishaw wrote:
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 errorERROR: cmake in the build tree failedI reran the test and specified the fortran compiler and got the testto 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.oPer 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_libIn 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.dylibLooking 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.0Here 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: 5Can 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. Thanks, Jim, for the above. It is going to take some time to completely absorb this information and other Mac OS X resources I found today, but my initial take is your results showed no use of rpath in the install tree because we set the INSTALL_NAME_DIR property (a property that is specific to Mac OS X that apparently supersedes rpath on that platform) for the library (see the current patched cmake/test_fortran/src_lib/CMakeLists.txt). It appears from your results that the INSTALL_NAME_DIR method does work for Mac OS X, but I would prefer to use the rpath approach to keep as parallel as possible with what goes on in the Linux case. I think the attached patch (which should be applied on top of the original unpatched source tree) should do that, i.e., it only drops rpath and uses INSTALL_NAME_DIR instead if the user has specified -DUSE_RPATH=OFF. So could you (and Jerry) try this patch instead and send me the test_fortran report tarball? Additional otool -l results to figure out rpath for the library and executable for both build tree and install tree would also be much appreciated. Thanks in advance. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________
rpath2.patch.gz
Description: revised patch to implement rpath processing for Mac OS X for test_fortran and test_ada
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
