From: Orion P. <or...@co...> - 2013-10-17 02:42:33
|
I'm getting the following rpmlint issues with the Fedora plplot 5.9.10 package: plplot-doc.noarch: E: zero-length /usr/share/doc/plplot/html/plplotdoc-html.proc Left over from something? plplot-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5 plplot-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5 plplot-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libplplotd.so.12.0.0 exit@GLIBC_2.2.5 plplot-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5 This library package calls exit() or _exit(), probably in a non-fork() context. Doing so from a library is strongly discouraged - when a library function calls exit(), it prevents the calling program from handling the error, reporting it to the user, closing files properly, and cleaning up any state that the program has. It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation. plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libm.so.6 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libgcc_s.so.1 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libquadmath.so.0 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libm.so.6 plplot-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libgcc_s.so.1 plplot-qt.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotqtd.so.1.0.0 /lib64/libQtXml.so.4 plplot-tk.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libSM.so.6 plplot-tk.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libICE.so.6 plplot-tk.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libXext.so.6 plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libfreetype.so.6 plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libm.so.6 plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libpthread.so.0 These libraries are unnecessarily linked with the specified library. 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? We need to have the .so installed with the execute bit set (like other .so's on rpm systems) and rpath stripped. plplot-octave.x86_64: W: unstripped-binary-or-object /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct similar to the above, needs to be installed with execute bit set. plplot-tk.x86_64: E: wrong-script-interpreter /usr/share/plplot5.9.10/examples/tk/tk02.in @xtk02_LOCATION@ plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk02.in 0644L @xtk02_LOCATION@ plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk03.in 0644L /bin/sh plplot-tk.x86_64: E: wrong-script-interpreter /usr/share/plplot5.9.10/examples/tk/tk04.in @xtk04_LOCATION@ plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk04.in 0644L @xtk04_LOCATION@ plplot-tk.x86_64: E: wrong-script-interpreter /usr/share/plplot5.9.10/examples/tcl/standard_examples.in @SH_EXECUTABLE@ plplot-tk.x86_64: E: wrong-script-interpreter /usr/share/plplot5.9.10/examples/tk/standard_examples.in @SH_EXECUTABLE@ plplot-tk.x86_64: E: wrong-script-interpreter /usr/share/plplot5.9.10/examples/tk/tk01.in @xtk01_LOCATION@ plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk01.in 0644L @xtk01_LOCATION@ Do we really want to install the .in files too? plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk03 0644L /bin/sh plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk02 0644L /usr/share/plplot5.9.10/examples/tk/xtk02 plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk01 0644L /usr/share/plplot5.9.10/examples/tk/xtk01 plplot-tk.x86_64: E: non-executable-script /usr/share/plplot5.9.10/examples/tk/tk04 0644L /usr/share/plplot5.9.10/examples/tk/xtk04 If these are meant to be executed directly (which the presence of a #! suggests), they should have the execute bit set. plplot.x86_64: E: script-without-shebang /usr/share/plplot5.9.10/examples/python/plplot_py_demos.py Not sure the point of this guy, but if it is meant to be executed directly it should have #!/usr/bin/python2 at the top, otherwise no execute bit. Thanks. - Orion -- 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 |
From: Alan W. I. <ir...@be...> - 2013-10-17 19:07:05
|
Hi Orion: Thanks very much for your report. There are so many issues involved, that I am going to answer you in several parts. This is part 1. On 2013-10-16 20:42-0600 Orion Poplawski wrote: > I'm getting the following rpmlint issues with the Fedora plplot 5.9.10 > package: > > plplot-doc.noarch: E: zero-length > /usr/share/doc/plplot/html/plplotdoc-html.proc > > Left over from something? Exactly. For some reason when xmlto produces html from our DocBook source (this method is still used now for html and will be used going forward), it creates that empty file which is then propagated further. I have fixed that (revision 12601) by deleting that file before propagation of the remaining files generated by xmlto. Please test this svn trunk fix. > > plplot-libs.x86_64: W: shared-lib-calls-exit > /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5 > plplot-libs.x86_64: W: shared-lib-calls-exit > /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5 > plplot-libs.x86_64: W: shared-lib-calls-exit > /usr/lib64/libplplotd.so.12.0.0 exit@GLIBC_2.2.5 > plplot-libs.x86_64: W: shared-lib-calls-exit > /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5 > > This library package calls exit() or _exit(), probably in a non-fork() > context. Doing so from a library is strongly discouraged - when a library > function calls exit(), it prevents the calling program from handling the > error, reporting it to the user, closing files properly, and cleaning up any > state that the program has. It is preferred for the library to return an > actual error code and let the calling program decide how to handle the > situation. This is an issue that has been with us for a while, but I agree it should be addressed. I strongly encourage discussing issues here first so our bug tracker doesn't get clogged with meaningless stuff, but this is a case where you should generate a report on our bug tracker for this so we don't lose it. More later for part 2. 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 __________________________ |
From: Andrew R. <and...@us...> - 2013-10-21 21:50:04
|
Orion, Thanks for the report. Lintian on Debian reports a number of the same issues. More comments below. On Thursday 17 Oct 2013 12:06:57 Alan W. Irwin wrote: > Hi Orion: > > Thanks very much for your report. There are so > many issues involved, that I am going to answer you in > several parts. > > This is part 1. > > On 2013-10-16 20:42-0600 Orion Poplawski wrote: > > I'm getting the following rpmlint issues with the Fedora plplot 5.9.10 > > package: > > > > plplot-doc.noarch: E: zero-length > > /usr/share/doc/plplot/html/plplotdoc-html.proc > > > > Left over from something? > > Exactly. For some reason when xmlto produces html from our DocBook > source (this method is still used now for html and will be used going > forward), it creates that empty file which is then propagated further. > I have fixed that (revision 12601) by deleting that file before > propagation of the remaining files generated by xmlto. > > Please test this svn trunk fix. For Debian I worked around the zero length file by just deleting the file myself in the packaging scripts. Better that Alan has now fixed upstream, but my approach works for the current release. > > plplot-libs.x86_64: W: shared-lib-calls-exit > > /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5 > > plplot-libs.x86_64: W: shared-lib-calls-exit > > /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5 > > plplot-libs.x86_64: W: shared-lib-calls-exit > > /usr/lib64/libplplotd.so.12.0.0 exit@GLIBC_2.2.5 > > plplot-libs.x86_64: W: shared-lib-calls-exit > > /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5 > > > > This library package calls exit() or _exit(), probably in a non-fork() > > context. Doing so from a library is strongly discouraged - when a library > > function calls exit(), it prevents the calling program from handling the > > error, reporting it to the user, closing files properly, and cleaning up > > any state that the program has. It is preferred for the library to return > > an actual error code and let the calling program decide how to handle the > > situation. > > This is an issue that has been with us for a while, but I agree it > should be addressed. I strongly encourage discussing issues here > first so our bug tracker doesn't get clogged with meaningless stuff, > but this is a case where you should generate a report on our bug > tracker for this so we don't lose it. This has been bounced around on the list a number of times (search the archives). Unfortunately it is a fairly fundamental result of the way plplot works. There is no graceful error handling and no way to propagate error codes back up from a function to the user. In light of this the only safe way to deal with a fatal error is to exit. The user can override this by changing the exit handler routine with plsexit, but this is likely to result in undefined behaviour. It wouldn't fix these warnings anyway. What plplot does is probably wrong, but to fix it properly would require a complete API change to allow functions to return an error code. We could do this, but it would be a large job and a huge API change. Shows the importance of making the right design decisions early on... It's in Alan's subsequent emails, but for reference I also get a number of warnings from lintian about unnecessary linkage. Those I understand I put down to false alerts. The ocaml ones I don't understand, so I'm glad Alan is delving deeper here. I'd be keen to test any improvements. Andrew |
From: Orion P. <or...@co...> - 2013-10-22 22:46:25
|
On 10/17/2013 01:06 PM, Alan W. Irwin wrote: > On 2013-10-16 20:42-0600 Orion Poplawski wrote: >> >> plplot-libs.x86_64: W: shared-lib-calls-exit >> /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5 >> plplot-libs.x86_64: W: shared-lib-calls-exit >> /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5 >> plplot-libs.x86_64: W: shared-lib-calls-exit >> /usr/lib64/libplplotd.so.12.0.0 exit@GLIBC_2.2.5 >> plplot-libs.x86_64: W: shared-lib-calls-exit >> /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5 >> >> This library package calls exit() or _exit(), probably in a non-fork() >> context. Doing so from a library is strongly discouraged - when a library >> function calls exit(), it prevents the calling program from handling the >> error, reporting it to the user, closing files properly, and cleaning up any >> state that the program has. It is preferred for the library to return an >> actual error code and let the calling program decide how to handle the >> situation. > > This is an issue that has been with us for a while, but I agree it > should be addressed. I strongly encourage discussing issues here > first so our bug tracker doesn't get clogged with meaningless stuff, > but this is a case where you should generate a report on our bug > tracker for this so we don't lose it. > FWIW - https://sourceforge.net/p/plplot/bugs/134/ -- 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 |
From: Alan W. I. <ir...@be...> - 2013-10-17 21:33:46
|
This is part 2 of my response concerning the overlinked libraries that rpmlint has turned up: On 2013-10-16 20:42-0600 Orion Poplawski wrote: > [out of order] These libraries are unnecessarily linked with the specified library. I started to reply in detail showing the ldd --unused results, for a number of these libraries, but in all cases where that command differed from your results with rpmlint, ldd had indicated a library was unnnecessarily linked which actually (according to nm --undefined-only) had to be linked. That is, there were man ldd --unused false positives. So here I am going to ignore the results from that command, and concentrate on the rpmlint results, what make VERBOSE=1 says is actually linked, and nm --undefined-only results to attempt to confirm the rpmlint results. > plplot-libs.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libm.so.6 > plplot-libs.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libgcc_s.so.1 > plplot-libs.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libquadmath.so.0 These are not brought in by CMake directly. Instead, they are the result of using the gfortran command to link (which is necessary because that brings in libraries that are needed). So unless Debian and Fedora change gfortran, rpmlint will continue to signal overlinking issues for libplplotf95d which should be ignored. ==> nothing to do here at the PLplot level. > plplot-libs.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libm.so.6 > plplot-libs.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libgcc_s.so.1 These are not brought in by CMake directly. Instead, they are the result of using the g++ command to link (which is necessary because that brings in libraries that are needed). So unless Debian and Fedora change g++, rpmlint will continue to signal overlinking issues for libplplotcxxd which should be ignored. ==> nothing to do here at the PLplot level. > plplot-qt.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotqtd.so.1.0.0 /lib64/libQtXml.so.4 I presume libQtXml is explicitly linked in because we use the CMake find(Qt4) command without any components specified. It is possible to use that command with explicit components, e.g., find(Qt4 QtCore QtGui QtXml) or find(Qt4 QtCore QtGui) But I haven't tried that because I am positive dropping QtXml would be a disaster for the svgqt device whose file format is XML, after all. In other words, I am virtually positive that libQtXml is an rmplint false positive. ==> nothing to do here. > plplot-tk.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libSM.so.6 > plplot-tk.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libICE.so.6 > plplot-tk.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libXext.so.6 These three overlinking issues have been fixed as of revision 12603. > plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libfreetype.so.6 > plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libm.so.6 > plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libpthread.so.0 I think these are likely real overlinking issues, but I am going to put off dealing with these because the on-going discussions on this list about how we might change the interface between PLplot and wxwidgets might result in a substantially simplified implementation that which might reduce or elminate some of the overlinking issues above. ########### This is the end of part 2. Later today I hope to respond to the rest of your e-mail for part 3. 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 __________________________ |
From: Orion P. <or...@co...> - 2013-10-22 03:34:40
|
On 10/17/2013 3:33 PM, Alan W. Irwin wrote: > This is part 2 of my response concerning the overlinked libraries > that rpmlint has turned up: > > On 2013-10-16 20:42-0600 Orion Poplawski wrote: > >> [out of order] These libraries are unnecessarily linked with the >> specified library. > > I started to reply in detail showing the ldd --unused results, for a > number of these libraries, but in > all cases where that command differed from your results with rpmlint, > ldd had indicated a library was unnnecessarily linked which actually > (according to nm --undefined-only) had to be linked. That is, there > were man ldd --unused false positives. So here I am going to > ignore the results from that command, and concentrate on the > rpmlint results, what make VERBOSE=1 says is actually linked, > and nm --undefined-only results to attempt to confirm the > rpmlint results. > > >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libm.so.6 >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libgcc_s.so.1 >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libquadmath.so.0 > > These are not brought in by CMake directly. Instead, they are the > result of using the gfortran command to link (which is necessary > because that brings in libraries that are needed). > > So unless Debian and Fedora change gfortran, rpmlint > will continue to signal overlinking issues for > libplplotf95d which should be ignored. > > ==> nothing to do here at the PLplot level. Agreed. >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libm.so.6 >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libgcc_s.so.1 > > These are not brought in by CMake directly. Instead, they are the > result of using the g++ command to link (which is necessary > because that brings in libraries that are needed). > > So unless Debian and Fedora change g++, rpmlint > will continue to signal overlinking issues for > libplplotcxxd which should be ignored. > > ==> nothing to do here at the PLplot level. Agreed. >> plplot-qt.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotqtd.so.1.0.0 /lib64/libQtXml.so.4 > > I presume libQtXml is explicitly linked in because we > use the CMake find(Qt4) command without any components > specified. It is possible to use that command with > explicit components, e.g., > > find(Qt4 QtCore QtGui QtXml) or > find(Qt4 QtCore QtGui) > > But I haven't tried that because I am positive dropping QtXml would be > a disaster for the svgqt device whose file format is XML, after all. > > In other words, I am virtually positive that libQtXml is an rmplint > false positive. Funny thing about library linkage - only if the plplotqtd code calls the QtXml library *directly* does it need to link to it. So I'm still not completely convinced. And the actual way to disable QtXml would normally be to set QT_USE_QTXML 0. However - the FindQt4 module enforces the linkage to QtXml if QtSvg is used, so it isn't a plplot issue. If I hack up cmake's UseQt4 to drop the QtXml dep everything still compiles and runs fine. >> plplot-tk.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libSM.so.6 >> plplot-tk.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libICE.so.6 >> plplot-tk.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libXext.so.6 > > These three overlinking issues have been fixed > as of revision 12603. Thanks. >> plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libfreetype.so.6 >> plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libm.so.6 >> plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libpthread.so.0 > > I think these are likely real overlinking issues, but I am going to > put off dealing with these because the on-going discussions on this > list about how we might change the interface between PLplot and > wxwidgets might result in a substantially simplified implementation > that which might reduce or elminate some of the > overlinking issues above. > ########### Makes sense. -- 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 |
From: Alan W. I. <ir...@be...> - 2013-10-18 00:24:06
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2013-10-18 02:19:37
|
Hi Orion: This is part 4 and the last part of my reply. On 2013-10-16 20:42-0600 Orion Poplawski wrote: > plplot-octave.x86_64: W: unstripped-binary-or-object > /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct > > similar to the above, needs to be installed with execute bit set. No, as stated in part 3 just treat this like you do all the rest of our libraries which all have the same non-execute permissions by default. > > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/tk02.in @xtk02_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk02.in 0644L @xtk02_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk03.in 0644L /bin/sh > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/tk04.in @xtk04_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk04.in 0644L @xtk04_LOCATION@ > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tcl/standard_examples.in @SH_EXECUTABLE@ > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/standard_examples.in @SH_EXECUTABLE@ > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/tk01.in @xtk01_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk01.in 0644L @xtk01_LOCATION@ > > Do we really want to install the .in files too? Yes, our cmake-based build system for the installed examples configures these files. If $prefix is the install prefix, see $prefix/share/plplot5.9.10/examples/tcl/CMakeLists.txt for the configuration of tcl/standard_examples and see $prefix/share/plplot5.9.10/examples/tk/CMakeLists.txt for the configuration of the rest of these. Also, if there is any question about the above permissions complaints for all of these *.in files, we deliberately set them to be executable in our source tree and also in the installed examples tree. They aren't actually meant to be executed so these execute permissions are technically incorrect (as noticed by rpmlint), but that permission automatically means the configured versions in both cases also have the appropriate execute permissions which is the result we want. There is probably a nicer way to get this result without setting technically incorrect execute bits on the *.in files, but I am not sure what it is. I will ask on the CMake list about this. > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk03 0644L /bin/sh > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk02 0644L > /usr/share/plplot5.9.10/examples/tk/xtk02 > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk01 0644L > /usr/share/plplot5.9.10/examples/tk/xtk01 > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk04 0644L > /usr/share/plplot5.9.10/examples/tk/xtk04 > > If these are meant to be executed directly (which the presence of a #! > suggests), they should have the execute bit set. This is what I have here: software@raven> pushd $prefix/share/plplot5.9.10/examples/tk where $prefix is my install prefix. software@raven> ls -lt *tk0* -rwxr-xr-x 1 software software 3766 Oct 17 13:26 tk01* -rwxr-xr-x 1 software software 3707 Mar 18 2013 tk01.in* -rwxr-xr-x 1 software software 4243 Oct 17 13:26 tk02* -rwxr-xr-x 1 software software 4184 Mar 18 2013 tk02.in* -rwxr-xr-x 1 software software 6294 Oct 17 13:26 tk03* -rwxr-xr-x 1 software software 6262 Mar 18 2013 tk03.in* -rwxr-xr-x 1 software software 2821 Oct 17 13:26 tk04* -rwxr-xr-x 1 software software 2762 Mar 18 2013 tk04.in* -rw-r--r-- 1 software software 12881 Mar 18 2013 xtk01.c -rw-r--r-- 1 software software 9103 Mar 18 2013 xtk02.c -rw-r--r-- 1 software software 5697 Mar 18 2013 xtk04.c I have explained the necessity of the *.in results above which are configured to a separate build tree without the .in suffix for the CMake-based build system of the installed examples. So technically those configured files in the build tree for that build system have nothing to do with the tk?? files in this source tree which are there for the use of our traditional build system and which are configured by the CMake-based build system _for our build tree_. So all is well on my platform with regard to permissions. It appears though that you might be getting different permissions for these files which I don't understand at all. I was confused a bit by the rpmlint mention of xtk0[124] files. However, that turns out to be just a mail wrap to an additional line of the rpmlint output that expresses what is found after #! for each of the configured tk0[124] files. Obviously, those xtk0[124] files should not be built except by interested users after rpm installation who want to test the system by trying the traditional or CMake-based build systems for the installed examples. To compare with my results above, what do you get for "ls -lt *tk0*" in the correct directory? > > plplot.x86_64: E: script-without-shebang > /usr/share/plplot5.9.10/examples/python/plplot_py_demos.py > > Not sure the point of this guy, but if it is meant to be executed > directly it should have #!/usr/bin/python2 at the top, otherwise no > execute bit. Again, it appears we differ in the permissions: irwin@raven> ls -l plplot_py_demos.py -rw-r--r-- 1 software software 41 Oct 4 17:39 plplot_py_demos.py What do you get for these permissions (in the installed examples tree)? That file is just a python module and not a python script so the above permissions are the correct ones. In sum, we appear to have different permissions for some of the files in the installed examples tree. It is obviously important that we figure out the cause of this. What happens if you just do an ordinary command-line install of PLplot without rpm being involved? Obviously, rpm does have the capability of fiddling with permission bits (required for example to set the executable bits on the libraries mentioned earlier in this thread to make the library permissions conform to Fedora standards). So please remove rpm from the equation to see whether that solves the issue. And if it does, (i.e., the permissions I demonstrate for the files above come out to be the same for you), then your spec file needs to be changed to not fiddle with those permissions. But if the permission results of the ordinary command line you get still differ from mine, than we will have to dig deeper. One possibility that might have an effect (but which should not) is the umask value. Mine is software@raven> umask 0022 I don't think the umask value should make any difference to the permissions of the CMake results, but if that turns out to be the case, the build system should be fixed so that installed results whose permissions have not been fiddled with by rpm should always have the same permissions achieved above on my platform. That's the end of part 4, and the end of my initial response to your detailed e-mail demonstrating issues found by rpmlint. This has been a number of hours of work for me to put this 4-part reply together, but I do very much appreciate your rpmlint reports because they often highlight areas that do need to be cleaned up. 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 __________________________ |
From: Orion P. <or...@co...> - 2013-10-18 03:47:38
|
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 or...@nw... Boulder, CO 80301 http://www.nwra.com |
From: Alan W. I. <ir...@be...> - 2013-10-18 06:02:05
|
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. To debug such different results for our two platforms, its essential to simplify the comparison as much as possible. So as a first step in that process would you be willing to try an ordinary command-line install of PLplot (i.e., without use of a spec file)? If the problem persists for that simpler case, then the next step after that is to simply the comparison _a lot_ more by me creating an extremely simple CMake project that installs one file to test for different install permissions on your platform versus mine. I am pretty sure we will find the cause of the problem somewhere before that last simplification stage, but if not, at the end we will have an extremely simple test case that I can take to the cmake developers. > >>> 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? 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 __________________________ |
From: Orion P. <or...@co...> - 2013-10-22 02:32:24
|
On 10/17/2013 8:19 PM, Alan W. Irwin wrote: > Hi Orion: > > This is part 4 and the last part of my reply. > > On 2013-10-16 20:42-0600 Orion Poplawski wrote: > >> plplot-octave.x86_64: W: unstripped-binary-or-object >> /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct >> >> similar to the above, needs to be installed with execute bit set. > > No, as stated in part 3 just treat this like you do all the > rest of our libraries which all have the same non-execute permissions > by default. Nope, you are setting the permissions explicitly: plplot-5.9.10/bindings/octave/CMakeLists.txt: # Have to be specific about permissions for some reason (probably oct suffix). set(PERM_MODULES OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ ) install(TARGETS plplot_octave EXPORT export_plplot LIBRARY DESTINATION ${OCTAVE_OCT_DIR} PERMISSIONS ${PERM_MODULES} ) If I remove the PERMISSIONS line, all is fine. The .oct is installed executable. > Also, if there is any question about the above permissions complaints > for all of these *.in files, we deliberately set them to be executable > in our source tree and also in the installed examples tree. They > aren't actually meant to be executed so these execute permissions are > technically incorrect (as noticed by rpmlint), but that permission > automatically means the configured versions in both cases also have > the appropriate execute permissions which is the result we want. > There is probably a nicer way to get this result without setting > technically incorrect execute bits on the *.in files, but I am > not sure what it is. I will ask on the CMake list about this. Thanks. >> plplot-tk.x86_64: E: non-executable-script >> /usr/share/plplot5.9.10/examples/tk/tk03 0644L /bin/sh >> plplot-tk.x86_64: E: non-executable-script >> /usr/share/plplot5.9.10/examples/tk/tk02 0644L >> /usr/share/plplot5.9.10/examples/tk/xtk02 >> plplot-tk.x86_64: E: non-executable-script >> /usr/share/plplot5.9.10/examples/tk/tk01 0644L >> /usr/share/plplot5.9.10/examples/tk/xtk01 >> plplot-tk.x86_64: E: non-executable-script >> /usr/share/plplot5.9.10/examples/tk/tk04 0644L >> /usr/share/plplot5.9.10/examples/tk/xtk04 >> >> If these are meant to be executed directly (which the presence of a #! >> suggests), they should have the execute bit set. > > This is what I have here: > > software@raven> pushd $prefix/share/plplot5.9.10/examples/tk > where $prefix is my install prefix. > > software@raven> ls -lt *tk0* > -rwxr-xr-x 1 software software 3766 Oct 17 13:26 tk01* > -rwxr-xr-x 1 software software 3707 Mar 18 2013 tk01.in* > -rwxr-xr-x 1 software software 4243 Oct 17 13:26 tk02* > -rwxr-xr-x 1 software software 4184 Mar 18 2013 tk02.in* > -rwxr-xr-x 1 software software 6294 Oct 17 13:26 tk03* > -rwxr-xr-x 1 software software 6262 Mar 18 2013 tk03.in* > -rwxr-xr-x 1 software software 2821 Oct 17 13:26 tk04* > -rwxr-xr-x 1 software software 2762 Mar 18 2013 tk04.in* > -rw-r--r-- 1 software software 12881 Mar 18 2013 xtk01.c > -rw-r--r-- 1 software software 9103 Mar 18 2013 xtk02.c > -rw-r--r-- 1 software software 5697 Mar 18 2013 xtk04.c Ah, sorry, I have: #Don't pull in script interpreters for example binaries chmod -x $RPM_BUILD_ROOT%{_datadir}/plplot%{version}/examples/tk/tk* .. > I was confused a bit by the rpmlint mention of xtk0[124] files. > However, that turns out to be just a mail wrap to an additional line > of the rpmlint output that expresses what is found after #! for each > of the configured tk0[124] files. Obviously, those xtk0[124] files > should not be built except by interested users after rpm installation > who want to test the system by trying the traditional or CMake-based > build systems for the installed examples. And that's why I did the chmod - otherwise rpm adds a dependency on /usr/share/plplot5.9.9/examples/tk/xtk01 (which is no good). There's a better way to handle this now in rpm though. >> >> plplot.x86_64: E: script-without-shebang >> /usr/share/plplot5.9.10/examples/python/plplot_py_demos.py >> >> Not sure the point of this guy, but if it is meant to be executed >> directly it should have #!/usr/bin/python2 at the top, otherwise no >> execute bit. > > Again, it appears we differ in the permissions: > > irwin@raven> ls -l plplot_py_demos.py > -rw-r--r-- 1 software software 41 Oct 4 17:39 plplot_py_demos.py > > What do you get for these permissions (in the installed examples tree)? > > That file is just a python module and not a python script so the > above permissions are the correct ones. > > In sum, we appear to have different permissions for some > of the files in the installed examples tree. It is obviously > important that we figure out the cause of this. This seems to be the cause: set( python_SCRIPTS ${python_SCRIPTS} ... plplot_py_demos.py And: set(PERM_SCRIPTS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE ) install(FILES ${python_SCRIPTS} ${CMAKE_CURRENT_BINARY_DIR}/test_plsmem.py DESTINATION ${DATA_DIR}/examples/python PERMISSIONS ${PERM_SCRIPTS} ) It should be part of python_DATA I suppose. > > This has been a number of hours of work for me to put this 4-part > reply together, but I do very much appreciate your rpmlint reports > because they often highlight areas that do need to be cleaned up. You are always extremely detail oriented. I hope you work pays off. Sorry for some false leads. -- 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 |
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 |
From: Alan W. I. <ir...@be...> - 2013-10-22 06:15:39
|
Hi Orion: I have read your several responses to my posts with interest, and I thank you for them. I think my reply to the last one below brings me up to date with your questions for me, but if I missed something, please bring it up again. On 2013-10-21 21:57-0600 Orion Poplawski wrote: >> @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. That setting is the cause of the empty result for libplplotd, but it will have no effect on dllplplot_stubs.so because our build system does not set rpath in that case (yet). So the fact that you get a non-empty result for dllplplot_stubs.so is a surprise since I get an empty result on my system. Also, it appears to me that rpath involves both the install tree and build tree which is a bad result. Since we do not deliberately produce such a bad rpath result upstream, I see two possibilities to explain this bad rpath result on Fedora. (1) This could be something intrinsic to the rpmbuild approach in which case you would have to ask other rpm builders how to get around it. You can find out whether this is the case by the process of eliminination. If the command line approach also has the problem, then it must be due to something besides the rpmbuild approach. (2) Debian's version of ocamlmklib does not set rpath by default when no -dllpath option is used,, but Fedora's version might set it to the above horrible value by default. In which case I suggest you attempt to use the following option -dllpath "" in the line starting with COMMAND ${OCAMLMKLIB} -o plplot_stubs ... in bindings/ocaml/CMakeLists.txt to see if that suppresses any default rpath used by the Fedora version of ocamlmklib. Anyhow, once Hez is in a position to respond to my rpath questions, I am pretty sure we will be specifying a definite value for -dllpath in the USE_RPATH=ON case, but for the USE_RPATH=OFF case we would either not specify -dllpath (which we do now and which produces the expected empty rpath on Debian) or use -dllpath "" if that works on Debian, and if you find that is necessary on Fedora. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2013-10-22 05:32:30
|
On 2013-10-21 20:32-0600 Orion Poplawski wrote: > On 10/17/2013 8:19 PM, Alan W. Irwin wrote: >> Hi Orion: >> >> This is part 4 and the last part of my reply. >> >> On 2013-10-16 20:42-0600 Orion Poplawski wrote: >> >>> plplot-octave.x86_64: W: unstripped-binary-or-object >>> /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct >>> >>> similar to the above, needs to be installed with execute bit set. >> >> No, as stated in part 3 just treat this like you do all the >> rest of our libraries which all have the same non-execute permissions >> by default. > > Nope, you are setting the permissions explicitly: Exactly, and for a deliberate reason. > > plplot-5.9.10/bindings/octave/CMakeLists.txt: > # Have to be specific about permissions for some reason (probably oct > suffix). > set(PERM_MODULES > OWNER_READ > OWNER_WRITE > GROUP_READ > WORLD_READ > ) > > install(TARGETS plplot_octave > EXPORT export_plplot > LIBRARY > DESTINATION ${OCTAVE_OCT_DIR} > PERMISSIONS ${PERM_MODULES} > ) > > If I remove the PERMISSIONS line, all is fine. The .oct is installed > executable. Yes, but upstream we set the above permissions deliberately to get consistent permission results with how the other PLplot libraries are installed upstream, i.e., with _no_ execute permission bits set. To see this for yourself, try a command line cmake ....; make install with a non-standard install prefix. That is how I test the upstream, and I would be greatly surprised if you got a different permission result than I do if you use my build and install method, i.e., use cmake with unique installation prefix and "make install" on the command line. 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. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2013-10-22 18:19:12
|
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 __________________________ |
From: Orion P. <or...@co...> - 2013-10-22 18:58:25
|
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 or...@nw... Boulder, CO 80301 http://www.nwra.com |
From: Andrew R. <and...@us...> - 2013-10-22 22:29:54
|
On Tuesday 22 Oct 2013 12:58:12 Orion Poplawski wrote: > On 10/22/2013 12:19 PM, Alan W. Irwin wrote: > > 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. Yes it would be a better location. For the Debian packages I override the default anyway. On Ubuntu and Debian (which are now multilib aware) octave files gets installed to /usr/lib/ARCH/octave/site/oct/*/plplot_octave.oct where ARCH is something like x86_64-linux-gnu as in Fedora. Actually on Debian it should probably be in /usr/lib/ARCH/octave/packages/plplot-5.8.10/ or similar. I'll look into changing the default so the plplot_octave.oct file is installed in $prefix/lib/octave/. The .oct files are loaded by octave, not the plplot code so we just need to ensure that the octave path is set correctly. Andrew |
From: Andrew R. <and...@us...> - 2013-10-23 08:53:10
|
On Tuesday 22 Oct 2013 23:29:40 Andrew Ross wrote: > On Tuesday 22 Oct 2013 12:58:12 Orion Poplawski wrote: > > On 10/22/2013 12:19 PM, Alan W. Irwin wrote: > > > 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. > > Yes it would be a better location. For the Debian packages I override the > default anyway. On Ubuntu and Debian (which are now multilib aware) octave > files gets installed to /usr/lib/ARCH/octave/site/oct/*/plplot_octave.oct > where ARCH is something like x86_64-linux-gnu as in Fedora. Actually on > Debian it should probably be in > /usr/lib/ARCH/octave/packages/plplot-5.8.10/ or similar. > > I'll look into changing the default so the plplot_octave.oct file is > installed in $prefix/lib/octave/. The .oct files are loaded by octave, not > the plplot code so we just need to ensure that the octave path is set > correctly. Turns out to be a one line fix as all the infrastructure is already there. The current behaviour is to use the octave configured directory for .oct file if the plplot install prefix is the same as the octave install prefix. If not, then install in ${CMAKE_INSTALL_DATADIR}/plplot_octave , which is clearly wrong as these are binary files. New behaviour changes CMAKE_INSTALL_DATADIR to CMAKE_INSTALL_LIBDIR. We _could_ adopt what we do for the .m files, which is to take the octave configured directory, strip off the octave install prefix and add the plplot install prefix. This may be unduly complicated. On my Ubuntu system this would result in .oct files going in ${CMAKE_INSTALL_PREFIX}/lib/x86_64-linux- gnu/octave/site/oct/x86_64-pc-linux-gnuoctave . The architecture dependent directories are a result of Ubuntu (and Debian) supporting multiple architectures on the same system (e.g. both 32 and 64 bit versions of libraries etc). Andrew |
From: Orion P. <or...@co...> - 2013-10-29 17:29:11
|
On 10/16/2013 08:42 PM, 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? We need to have the .so installed with the execute bit set (like > other .so's on rpm systems) and rpath stripped. Seems to be an upstream ocaml bug: http://caml.inria.fr/mantis/view.php?id=5943 -- 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 |
From: Alan W. I. <ir...@be...> - 2013-10-30 03:44:25
|
On 2013-10-29 11:29-0600 Orion Poplawski wrote: > On 10/16/2013 08:42 PM, 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? We need to have the .so installed with the execute bit set (like >> other .so's on rpm systems) and rpath stripped. > > Seems to be an upstream ocaml bug: > > http://caml.inria.fr/mantis/view.php?id=5943 Hi Orion: That does sound like the issue, but the explanation is probably more complicated than described there since there are cases (e.g. on my Debian system) where the bug is not active (e.g., no rpath is set as proved by objdump). Anyhow, from that report it looks like the bugfix is scheduled to go into the next OCaml release which should presumably not affect the empty rpath results I have on my OCaml platform but which should presumably replace the weird rpath setting on yours with the expected empty results. 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 __________________________ |