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 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 On Linux (from my own comprehensive test of test_fortran where I happened to set the environment variable FFLAGS=-O3 -Wuninitialized -Wunused ) the equivalents of these two commands are /usr/bin/f95 -fPIC -O3 -Wuninitialized -Wunused -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0 CMakeFiles/hello_1.dir/hello_1.f90.o -Wl,-rpath,:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: and /usr/bin/f95 -O3 -Wuninitialized -Wunused CMakeFiles/hello.dir/hello.f90.o -o hello ../src_lib/libhello.so.0.0 -Wl,-rpath,/home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib The test_fortran project (and test_ada and plplot projects) do not do anything special for rpath in the build tree so the above is what CMake does by default for the build tree. 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 and /usr/bin/f95 -O3 -Wuninitialized -Wunused CMakeFiles/hello.dir/hello.f90.o -o hello /home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.so.0.0 -Wl,-rpath,/home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib 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. 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 otool. Furthermore, on Linux, to look deeper to find exactly what rpath is set for a library or executable you would use (see <http://stackoverflow.com/questions/2836330/is-there-a-way-to-inspect-the-current-rpath-on-linux>) objdump -x binary-or-library |grep -E 'RPATH|RUNPATH' or readelf -d binary-or-library |head -20 For my test_fortran result here, the installed hello executable is located at ~/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_build_tree/fortran so if I cd to that directory and use either one of the above methods, I get the result that the installed library location, /home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib is the rpath location (as expected). Is either objdump or readelf available to you on Mac OS X so you can do a similar test there? Once I am satisfied concerning the otool and either objdump or readelf results that rpath is working properly for (the patched) test_fortran project on Mac OS X platforms, then I intend to modify the plplot project to use that working rpath method for Mac OS X platforms. So further investigation by you or someone else along the lines I have suggested above is important. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
