From: Orion P. <or...@co...> - 2013-10-22 03:57:43
|
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 or...@nw... Boulder, CO 80301 http://www.nwra.com |