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.
To debug such different results for our two platforms, its essential
to simplify the comparison as much as possible. So as a first step in
that process would you be willing to try an ordinary command-line
install of PLplot (i.e., without use of a spec file)? If the problem
persists for that simpler case, then the next step after that is to
simply the comparison _a lot_ more by me creating an extremely simple
CMake project that installs one file to test for different install
permissions on your platform versus mine. I am pretty sure we will
find the cause of the problem somewhere before that last
simplification stage, but if not, at the end we will have an extremely
simple test case that I can take to the cmake developers.
>
>>> 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?
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
__________________________
------------------------------------------------------------------------------
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=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
