On 2013-10-21 22:32-0700 Alan W. Irwin wrote:
> Anyhow, we definitely have a difference in permission results if you
> use rpmbuild and your spec file on your system compared to the above
> command-line approach on my system. Regardless of whether you decide
> to try the command line approach to verify that the rpmbuild approach
> is somehow messing with permissions, I presume it is straightforward
> for you to use the chmod command appropriately in your spec file to
> deal with the permissions mentioned by rpmlint that are not already
> the permission result that rpmlint wants.
Hi Orion (with question at the end for Andrew):
Sometimes my brain works better when I am asleep. :-) I woke up this
morning with the obvious idea that I should double check my instincts
by actually doing a google search on cmake and library permissions.
That quickly lead me to
$prefix/share/cmake-2.8/Modules/Platform/Linux.cmake which has the
following CMake logic:
# Debian policy requires that shared libraries be installed without
# executable permission. Fedora policy requires that shared libraries
# be installed with the executable permission. Since the native tools
# create shared libraries with execute permission in the first place a
# reasonable policy seems to be to install with execute permission by
# default. In order to support debian packages we provide an option
# here. The option default is based on the current distribution, but
# packagers can set it explicitly on the command line.
if(DEFINED CMAKE_INSTALL_SO_NO_EXE)
# Store the decision variable in the cache. This preserves any
# setting the user provides on the command line.
set(CMAKE_INSTALL_SO_NO_EXE "${CMAKE_INSTALL_SO_NO_EXE}" CACHE INTERNAL
"Install .so files without execute permission.")
else()
# Store the decision variable as an internal cache entry to avoid
# checking the platform every time. This option is advanced enough
# that only package maintainers should need to adjust it. They are
# capable of providing a setting on the command line.
if(EXISTS "/etc/debian_version")
set(CMAKE_INSTALL_SO_NO_EXE 1 CACHE INTERNAL
"Install .so files without execute permission.")
else()
set(CMAKE_INSTALL_SO_NO_EXE 0 CACHE INTERNAL
"Install .so files without execute permission.")
endif()
endif()
So the conclusion is you were absolutely right, and my instincts were
wrong; native CMake does generate different permission bits for
installed *.so files depending on the Linux platform. So with
revision 12617 I have changed the installation of the Octave and OCaml
shared objects to use the correct permissions according to the
CMAKE_INSTALL_SO_NO_EXE variable. The result should be consistent
permissions (either all 644 or all 755 depending on platform) for all
shared objects.
Sorry my instincts were leading me astray, but I got there in the end.
I think the only outstanding issue at this stage from your original
report is the bad rpath on the dll*.so OCaml files. To resolve that
is going to require some more information from you (results from
invoking cmake and make install on the command line, and if the
trouble persists trying -dllpath "" for that).
One other issue I noticed this morning is that the shared object
plplot_octave.oct is installed in
$prefix/share/plplot_octave/plplot_octave.oct. I am positive
rpmlint will start complaining about the install location of that
file once its permissions are executable. I assume it should
go somewhere in the $prefix/lib tree instead.
@Andrew:
Would $prefix/lib/octave/plplot_octave.oct be a better location, and
if so, would you take responsibility for fixing it please? Assuming
you do decide to change the location, there will be a number of issues
for that changed location revealed by the shared/dynamic devices
subset of scripts/comprehensive_test.sh. That script runs both
non-interactive and interactive tests for the build tree, and the two
different build systems for the installed examples, and it will be a
matter of knocking off those issues one by one as you find them via
those comprehensive tests.
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=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
