On 10/18/2013 12:01 AM, Alan W. Irwin wrote:
> Hi Hez: Look for @Hez: below and continue reading until you hit @Orion.
>
> Hi Orion: vice versa for you. :-)
>
> On 2013-10-17 21:47-0600 Orion Poplawski wrote:
>
>> On 10/17/2013 6:23 PM, Alan W. Irwin wrote:
>>> To Hez and Orion:
>>>
>>> This is part 3 of my reply to Orion's post. But as a result
>>> I found an rpath deficiency in our OCaml build which leads
>>> to questions for Hez below which is why this is primarily
>>> directed to both Hez and Orion.
>>>
>>> On 2013-10-16 20:42-0600 Orion Poplawski wrote:
>>>
>>>> plplot-ocaml.x86_64: W: unstripped-binary-or-object
>>>> /usr/lib64/ocaml/stublibs/dllplplot_stubs.so
>>>> plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath
>>>> /usr/lib64/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib64/ocaml',
>>>> '/builddir/build/BUILD/plplot-5.9.10/fedora/src']
>>>> plplot-ocaml.x86_64: W: unstripped-binary-or-object
>>>> /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so
>>>> plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath
>>>> /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib64',
>>>> '/builddir/build/BUILD/plplot-5.9.10/fedora/src']
>>>>
>>>> I'm assuming these are arising because cmake does not natively handle
>>>> ocaml?
>>>
>>> @Orion: We do have a home-brew system to build what is needed for OCaml,
>>> but
>>> on the permissions issue we were careful to follow what is done for
>>> our other non-ocaml libraries that are built by more conventional
>>> CMake means.
>>>
>>>> We need to have the .so installed with the execute bit set (like
>>>> other .so's on rpm systems)....
>>>
>>> No. The problem is other Linux distros (e.g., Debian) do not agree on
>>> this issue. By historical accident we decided to adopt the Debian
>>> convention so the above files conform to that as well as our normal
>>> PLplot libraries. So for the above files you just have to do what you
>>> did for other PLplot libraries. (Unless I am missing something.)
>>
>> Well, I do nothing special for the Fedora builds. I would assume then
>> that cmake is able to determine the proper permission to use on Fedora
>> for most libraries, but for some reason this is not being applied to
>> the OCaml libraries.
>
> @Orion:
> The different install permissions between your platform and mine
> appear to be the cause of a number of issues you brought up in your
> initial post in this thread. That includes this issue. But I am pretty
> sure that CMake treats all Linux systems the same. So I think a more
> likely explanation is some other factor that is different between our
> two platforms is affecting the permissions on installed files.
>
From the bindings/ocaml and bindings/ocaml/plcairo CMakeFiles.txt files:
# Shared library stubs go in stublibs
# Use default permissions (rw-r--r--) for FILES signature because
# those are the permissions used by install(TARGETS... (which
# we are trying to emulate here because that signature not
# available to us because this shared object was
# created by a custom command).
install(
FILES ${CMAKE_CURRENT_BINARY_DIR}/dllplcairo_stubs.so
DESTINATION ${OCAML_INSTALL_DIR}/stublibs
)
So there you go - but you are emulating Debian style permissions.
>>
>>>> and rpath stripped.
>>>
>>> I think you meant symbols stripped. Which is what you have to
>>> do with all our libraries.
>>
>> No, I mean rpath - rpmlint is complaining about the /usr/lib64 rpath
>> in the library.
>
> @Orion: my next comment will be to Hez because there are some
> preliminary comments
> and embedded questions for him I have to get out of the way before
> answering what you said just above.
>
> @Hez: I have looked more carefully at what we put together
> years ago, and from our terse note in bindings/ocaml/CMakeLists.txt
> which consists of
>
> # ocamlmklib links *.o into *.so and *.a
>
> and the fact that one of the output files of that custom_command
> is ${CMAKE_CURRENT_BINARY_DIR}/dllplplot_stubs.so, I infer it
> is ocamlmklib that is internally controlling RPATH options for
> the link of dllplplot_stubs.so in the build tree. If you look
> at the man page for ocamlmklib, there are several different
> rpath options that set rpath (e.g.,
>
> -dllpath dir
>
> and its synonyms
>
> -rpath dir
> -Rdir
> -Wl, -rpath dir
> -Wl, -rpath -Wl dir
> -Wl, -Rdir
>
> So using -dllpath (or one of its synonyms) should solve the issue of
> getting libplplotd recognized by the run-time loader in the build tree
> and also the install tree that I mentioned before for the built
> dllplplot_stubs.so and dllplcairo_stubs.so files. But before
> implementing that, I need a test from you that actually uses these
> files to show that I am setting rpath correctly for these files.
>
> @Orion: Note we use none of the above options for
> ocamlmklib at the moment and we simply install the result as a file
> in the install tree (although that will change when
> I address the issue above).
>
> Could you confirm rpath settings on your platform using
>
> readelf -d *.so |grep rpath
>
> for the installed version of libplplotd and dllplplot_stubs?
I get this for both the installed and build dir of dllplplot_stubs.so:
$ readelf -d ./usr/lib64/ocaml/stublibs/dllplplot_stubs.so | grep rpath
0x000000000000000f (RPATH) Library rpath:
[/usr/lib64/ocaml:/export/home/orion/fedora/plplot/plplot-5.9.10/fedora/src]
$ readelf -d ./usr/lib64/libplplotd.so.12 | grep rpath
$
I also set USE_RPATH=NO.
> If I first cd to $prefix/lib I get the following results here:
>
> irwin@raven> readelf -d libplplotd.so |grep rpath
> 0x000000000000000f (RPATH) Library rpath:
> [/home/software/plplot_svn/installcmake/lib:/usr/lib/x86_64-linux-gnu:/home/software/qhull/install/lib:/home/software/shapelib/install/lib]
>
>
> irwin@raven> readelf -d ocaml/stublibs/dllplplot_stubs.so |grep rpath
> ==> no results at all.
>
> Those are the expected results for libplplotd. That libplplotd rpath
> information collects all those different install locations for the
> library dependencies of libplplotd. You will get a similar result for
> a command-line install of PLplot which sets USE_RPATH to ON because
> you will likely have a non-standard install prefix (which allows you
> to run make install as an ordinary user). But as you can see with
> many different non-standard install prefixes for a variety of
> libraries, the rpaths can get a bit complicated. But it all works
> fine in an automated way thanks to CMake logic that I have built up
> over the years to cater to my needs for many different install
> prefixes.
>
> In contrast, readelf -d shows there is no rpath result for
> dllplplot_stubs.so which is expected since we do not (yet) use
> any of the ocamlmklib options listed above to set rpath.
>
> Do you get the same empty result there for rpath of
> $prefix/lib/ocaml/stublibs/dllplplot_stubs.so or do you confirm the
> rpmlint finding with readelf -d? If so, then that is a completely
> unexpected result which might be caused by rpmbuild automatically
> doing something it shouldn't while it processes your spec file for
> PLplot. Anyhow, if rpath is set inappropriately for the rpmbuild
> results according to readelf -d, just do an ordinary command line
> install of PLplot using cmake and "make install" to see whether for
> that case rpath does not occur at all for the installed
> dllplplot_stubs.so like I confirm above on my platform. As in the
> different installed permissions cases on our two platforms, the proper
> way to debug this is to keep simplifying. And replacing rpmbuild of a
> spec file by a simple cmake and make install approach is the first
> step in that process.
>
> 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
> __________________________
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane [email protected]
Boulder, CO 80301 http://www.nwra.com
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
