Turned Rpath Support On For Mac
Attachments: Hi Jim (and any others here with access to Mac OS X): I need some fairly urgent help with a test of a potential rpath change for Mac OS X. If you have time to help out this way, please apply the attached patch to the latest update of the master branch, then follow the directions in cmake/testfortran/README to comprehensively test that tiny Fortran project (which the attached patch updates to use the rpath option on Mac OS X) using the trace option. (Those directions should boil down to cd cmake/testfortran scripts/comprehensivetest.sh -dotrace yes.) When the test has completed (which normally should take only a second or so) please send me the resulting report tarball (which should be stored at./././comprehensivetestfortrandisposeable/comprehensivetest.tar.gz). To give you some background on why I need this test result, on Linux our build system uses the default rpath method that is normally employed by CMake for the build tree, and by default uses that same method for the installed examples. However, when we were putting all this logic together a decade ago the Mac OS X version was 10.4 = 'Tiger' which did not honor rpath.
Accordingly at that time, CMake did not use rpath in the build tree and we disabled rpath in the install tree just for the Mac OS X case. Of course, that caused find problems for the run-time loader if the install location was nonstandard so to workaround that issue we asked users to fiddle with the DYLDLIBRARYPATH brute-force technique when installing by hand (or else our comprehensive test script did that when testing installed versions). Fast forward to today. Mac OS X 10.5 = 'Leopard' (which was released in 2007) and all later versions honor rpath according to comments at.
Attachments: Hi Jim (and any others here with access to Mac OS X): I need some fairly urgent help with a test of a potential rpath change for Mac OS X. If you have time to help out this way, please apply the attached patch to the latest update of the master branch, then follow the directions in cmake/testfortran/README to comprehensively test that tiny Fortran project (which the attached patch updates to use the rpath option on Mac OS X) using the trace option. (Those directions should boil down to cd cmake/testfortran scripts/comprehensivetest.sh -dotrace yes.) When the test has completed (which normally should take only a second or so) please send me the resulting report tarball (which should be stored at./././comprehensivetestfortrandisposeable/comprehensivetest.tar.gz). To give you some background on why I need this test result, on Linux our build system uses the default rpath method that is normally employed by CMake for the build tree, and by default uses that same method for the installed examples.
However, when we were putting all this logic together a decade ago the Mac OS X version was 10.4 = 'Tiger' which did not honor rpath. Accordingly at that time, CMake did not use rpath in the build tree and we disabled rpath in the install tree just for the Mac OS X case. Of course, that caused find problems for the run-time loader if the install location was nonstandard so to workaround that issue we asked users to fiddle with the DYLDLIBRARYPATH brute-force technique when installing by hand (or else our comprehensive test script did that when testing installed versions). Fast forward to today. Mac OS X 10.5 = 'Leopard' (which was released in 2007) and all later versions honor rpath according to comments at.
Attachments: On Aug 21, 2016, at 5:55 PM, Alan W. Irwin wrote: Hi Jim (and any others here with access to Mac OS X): I need some fairly urgent help with a test of a potential rpath change for Mac OS X. If you have time to help out this way, please apply the attached patch to the latest update of the master branch, then follow the directions in cmake/testfortran/README to comprehensively test that tiny Fortran project (which the attached patch updates to use the rpath option on Mac OS X) using the trace option.
(Those directions should boil down to cd cmake/testfortran scripts/comprehensivetest.sh -dotrace yes.) When the test has completed (which normally should take only a second or so) please send me the resulting report tarball (which should be stored at./././comprehensivetestfortrandisposeable/comprehensivetest.tar.gz). The build environment: Mac OS X 10.11.6, Apple LLVM version 7.3.0 (clang-703.0.31), GNU Fortran (MacPorts gcc5 5.4.00) 5.4.0 I created a new clone of the repository from source forge. I applied the patch and git status lists the following modified files modified: cmake/testada/CMakeLists.txt modified: cmake/testada/scripts/comprehensivetest.sh modified: cmake/testfortran/CMakeLists.txt modified: cmake/testfortran/scripts/comprehensivetest.sh I followed the configuration and build instructions as outlined in the manual. I had to specify the fortran compiler (I have two different versions on my system and neither is linked to gfortran—by default MacPorts installs as gfortran-mp-versionnumber, e.g gfortran-mp-5).
There were several errors in the cmake output, most appeared to be related to Ada and D (neither are installed on my system). There was one Fortran related error: CMake Error at cmake/modules/pkg-config.cmake:228 (string): string sub-command REGEX, mode REPLACE needs at least 6 arguments total to command. Call Stack (most recent call first): cmake/modules/pkg-config.cmake:399 (pkgconfiglinkflags) bindings/f95/CMakeLists.txt:202 (pkgconfigfile) There was also errors in CMakeFiles/CMakeError.log (see attached). Hi Jim: You said: I ran the comprehensive test suite presumably for testfortran 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 testfortran 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. According to discussion in.
According to. Attachments: On Aug 22, 2016, at 1:19 PM, Alan W. Irwin wrote: Hi Jim: You said: I ran the comprehensive test suite presumably for testfortran 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 testfortran project indeed seems to work, but I have further questions about what goes on with the Mac OS X rpath manipulationsand if you don't have the Mac OS X linking experience to answer thoseI hope someone else from this list does. Here is what is bothering me about the Mac OS X rpath manipulations. Specifically (see shared/noninteractive/outputtree/makenoninteractive.out) in the build tree, the library build is done using /opt/local/bin/gfortran-mp-5 -dynamiclib -Wl,-headerpadmaxinstallnames -o libhello.0.0.dylib -installname @rpath/libhello.0.dylib CMakeFiles/hello1.dir/hello1.f90.o Per the Apple documentation 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./srclib/libhello.0.0.dylib -Wl,-rpath,/Users/jim/Development/plplot2/comprehensivetestfortrandisposeable/shared/noninteractive/buildtree/srclib 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 “@loaderpath” is used. In the install tree (see shared/noninteractive/outputtree/makenoninteractive.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/comprehensivetestfortrandisposeable/shared/noninteractive/installtree/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. Attachments: On 2016-08-23 Jim Dishaw wrote: On Aug 22, 2016, at 1:19 PM, Alan W. Irwin wrote: Hi Jim: You said: I ran the comprehensive test suite presumably for testfortran 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 testfortran project indeed seems to work, but I have further questions about what goes on with the Mac OS X rpath manipulationsand if you don't have the Mac OS X linking experience to answer thoseI hope someone else from this list does.
Turned Rpath Support On For Mac Pro
Here is what is bothering me about the Mac OS X rpath manipulations. Specifically (see shared/noninteractive/outputtree/makenoninteractive.out) in the build tree, the library build is done using /opt/local/bin/gfortran-mp-5 -dynamiclib -Wl,-headerpadmaxinstallnames -o libhello.0.0.dylib -installname @rpath/libhello.0.dylib CMakeFiles/hello1.dir/hello1.f90.o Per the Apple documentation 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./srclib/libhello.0.0.dylib -Wl,-rpath,/Users/jim/Development/plplot2/comprehensivetestfortrandisposeable/shared/noninteractive/buildtree/srclib 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 “@loaderpath” is used. In the install tree (see shared/noninteractive/outputtree/makenoninteractive.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/comprehensivetestfortrandisposeable/shared/noninteractive/installtree/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. On 2016-08-23 Alan W. Irwin wrote:. It appears. that the INSTALLNAMEDIR 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 INSTALLNAMEDIR instead if the user has specified -DUSERPATH=OFF. So could you (and Jerry) try this patch instead and send me the testfortran 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. Jerry kindly came through with that requested test of the new patch, and indeed, his report tarball indicated the rpath method was used for the installed examples linking as expected for that particular patch.
Furthermore, his report showed the test of that method of linking worked perfectly for testfortran. Encouraged by that limited success, I have changed the entire PLplot project to use the rpath linking method for installed examples by default on Mac OS X just like what occurs in the Linux case. See commit 5314c65 which supersedes the limited testfortran (and testada) patches I have been asking Jerry and Jim to test. @Jerry and Jim: Please test commit 5314c65 (without any additional patching) on your Mac OS X platforms using (N.B.
From the top-level directory in the PLplot source tree so this is a test of the plplot project and not either of the testada or testfortran projects) scripts/comprehensivetest.sh -cmakeaddedoptions '-DDEFAULTNODEVICES=ON -DPLDps=ON -DDEFAULTNOBINDINGS=ON -DENABLEf95=ON' -dotestinteractive no This comprehensive test of the plplot project restricts the components of PLplot that are tested to just the ps and psc devices, just the Fortran binding, and just noninteractive tests. Those restrictions considerably speeds up this test (which only took 6 minutes on my 7-yr-old PC with these restrictions). This test of the PLplot Fortran binding and examples is obviously much more substantial than the equivalent test of the extremely simple testfortran project. In particular, the above script invocation tests the traditional (make + pkg-config) build of the installed Fortran examples without DYLDLIBRARYPATH manipulations.
My guess is the new rpath linking method for the installed examples will allow that to work, but I do need one or both of you to confirm that. @Jim: You stated recently that you had some trouble with getting the Fortran parts of PLplot to work on Mac OS X. If that is still the case, the report tarball generated by the above script invocatin will likely give me everything I need to fix that issue. 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. On Aug 25, 2016, at 3:19 PM, Alan W. Irwin wrote: @Jim: You stated recently that you had some trouble with getting the Fortran parts of PLplot to work on Mac OS X. If that is still the case, the report tarball generated by the above script invocatin will likely give me everything I need to fix that issue.
The issue is that MacPorts had installed gfortran as gfortran-mp-49 and gfortran-mp-5. There was no gfortran executable. I don't know if that is normal or an artifact of having two different versions installed. The fix was simple-I set FC=/opt/local/bin/gfortran-mp-5 We could fix the cmake configuration to try different names or just document it in the wiki. Alan Alan W.
Irwin Astronomical research affiliation with Department of Physics and AstronomyUniversity 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.
On 2016-08-25 Jim Dishaw wrote: On Aug 25, 2016, at 3:19 PM, Alan W. Irwin wrote: @Jim: You stated recently that you had some trouble with getting the Fortran parts of PLplot to work on Mac OS X. If that is still the case, the report tarball generated by the above script invocatin will likely give me everything I need to fix that issue. The issue is that MacPorts had installed gfortran as gfortran-mp-49 and gfortran-mp-5. There was no gfortran executable. I don't know if that is normal or an artifact of having two different versions installed.
The fix was simple-I set FC=/opt/local/bin/gfortran-mp-5 We could fix the cmake configuration to try different names or just document it in the wiki. My feeling is CMake itself and the PLplot build system should not be expected to support idiosyncratic platform names for the Fortran (or any other) compiler in a seamless manner. So I suggest you just document the use of the FC environment variable.
By the way, Linux distributions typically handle multiple versions of any tool by an extremely convenient update-alternatives script (which, for example, would symbolically link gfortran to the version preferred by the user). Back in 2008, this possibility was discussed for MacPorts (see.