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.)
> and rpath stripped.
I think you meant symbols stripped. Which is what you have to
do with all our libraries.
However, your mentioning of rpath and ocaml lead to me opening up a
can of worms which is that I discovered rpath is not mentioned at all
in bindings/ocaml/CMakeLists.txt or
bindings/ocaml/plcairo/CMakeLists.txt. So the rest of this
is primarily directed to Hez:
@Hez: rpath not being used in the build tree is contrary to what CMake
does by default in the build tree for normal libraries which is to use
rpath everwhere to keep track of the wide variety of different
build-tree locations that occur for Linux.
This deficiency for the OCaml part of our build system should
(although it doesn't, see my question for you below) affect everybody's
attempts to test our ocaml bindings in the build tree.
Here is the current situation in the build tree.
software@raven> ldd bindings/ocaml/dllplplot_stubs.so
[...]
libplplotd.so.12 => not found
[...]
software@raven> ldd bindings/ocaml/plcairo/dllplcairo_stubs.so
[...]
libplplotd.so.12 => not found
[...]
which means that dllplplot_stubs.so and dllplcairo_stubs.so
are completely unusable in the build tree by the run-time loader.
How come we haven't run into any test issues because libplplotd
cannot be found when the run-time loader attempts to load our ocaml
libraries ? Are dllplplot_stubs.so and dllplcairo_stubs.so never
actually used by our build-tree tests? Or might these not
be normal libraries so the run-time loader would never be
expected to load them?
Now we move to a different part of the can of worms which is that no
rpath is set in the install tree either. We don't use the CMake
default for this (no rpath in install tree). Instead, for our other
libraries and only if USE_RPATH is ON (which it isn't for Fedora or
Debian package building since there is a normal package installation
prefix in that case) we normally set rpath appropriately for whatever
install prefix is set. So here are the current results for the
install tree location:
software@raven> ldd
/home/software/plplot_svn/installcmake/lib/ocaml/stublibs/dllplplot_stubs.so
[...]
libplplotd.so.12 => not found
[...]
software@raven> ldd
/home/software/plplot_svn/installcmake/lib/ocaml/stublibs/dllplcairo_stubs.so
[...]
libplplotd.so.12 => not found
[...]
@Hez: Same question as above but in this case for the installed version.
This is the end of part 3 of my reply (which mostly ended up as
questions for Hez). There is at least one more part to come.
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
