Re: [Plplot-devel] Potential Mac OS X rpath change needs testing on that platformu

[Alan W. I. <ir...@be...>]

On 2016-08-23 21:29-0400 Jim Dishaw wrote:

>
>> On Aug 22, 2016, at 1:19 PM, Alan W. Irwin <ir...@be...> 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.

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
__________________________