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. >> 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. > 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 > __________________________ -- 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=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
