On 10/22/2013 12:19 PM, Alan W. Irwin wrote:
> 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.
Yup, no worries.
> 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).
I'll try to get to that soon.
> 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.
On Fedora it installs to:
%{_libdir}/octave/site/oct/*/plplot_octave.oct
with no trouble on my side, so I think we are okay at least on Fedora. I
think it gets the path from the octave.
> @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
> __________________________
--
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=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
