On 05/18/2015 01:35 AM, Alan W. Irwin wrote: > Hi Hez: > > Can you evaluate Patch7 below that removes the -custom option > from our ocamlc build commands? > > @Orion and Andrew: the rest of this response is addressed to you > as our respective Fedora and Debian packagers. > > On 2015-04-25 12:42-0600 Orion Poplawski wrote: > >> On 04/25/2015 11:05 AM, Alan W. Irwin wrote: >>> While we are at it, are there any other general issues like this one >>> (i.e., issues likely to affect all distros) addressed by the Fedora >>> downstream patches which we should be aware of upstream? >> >> There are two other issues currently addressed downstream, which I'm pretty >> sure I've raised here before. The ocaml one relatively recently, not sure >> about the multiarch one. >> >> Patch2: plplot-multiarch.patch >> >> This allows for the "core" plplot package to be "multiarch" - exactly the >> same content for 32-bit and 64-bit builds. Otherwise the PKG_CONFIG_ENV and >> RPATH variables have /usr/lib or /usr/lib64 in them. I know this patch >> isn't acceptable upstream as it is, but if you found a way to address it, >> that would be great. > > Patch2a: PKG_CONFIG_ENV > > I have now (commit id 2b4e397) implemented a user-configurable location called > CMAKE_INSTALL_PKG_CONFIG_DIR where the PLplot *.pc files are > installed. The default value for this cached variable is > > $prefix/share/pkgconfig > > which is apparently what Debian wheezy uses for multiarch *.pc files. > > @Andrew: can you confirm that location for modern Debian? > > @Orion: If that default location is not right for the Fedora multiarch > needs, try setting CMAKE_INSTALL_PKG_CONFIG_DIR on the cmake command > line.
*If* the pkgconfig files were "multiarch"/noarch, that would be the place to install them. However, they are not noarch - they contain /usr/lib or /usr/lib64 depending on the architecture: plplot-ada.pc:libdir=/usr/lib64 plplot-ada.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-ada.pc:Libs.private: -L"${libdir}" -L"/usr/lib64" -lgnat-5 plplot-c++.pc:libdir=/usr/lib64 plplot-c++.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-f95.pc:libdir=/usr/lib64 plplot-f95.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-f95.pc:Cflags: -I"${includedir}" -I"/usr/lib64/gfortran/modules" plplot-ocaml.pc:libdir=/usr/lib64 plplot-ocaml.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot.pc:libdir=/usr/lib64 plplot.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot.pc:Libs.private: -L"${libdir}" -L"/usr/lib64" -lltdl -L"/usr/lib64" -lm -L"/usr/lib64" -lshp -L"/usr/lib64" -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime plplot-qt.pc:libdir=/usr/lib64 plplot-qt.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-qt.pc:Libs: -L"${libdir}" -lplplotqt -L"/usr/lib64" -lQtSvg -L"/usr/lib64" -lQtGui -L"/usr/lib64" -lQtCore plplot-qt.pc:Libs.private: -L"${libdir}" -lplplot -L"/usr/lib64" -lm plplot-tcl_Main.pc:libdir=/usr/lib64 plplot-tcl_Main.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-tcl_Main.pc:Libs.private: -L"${libdir}" -lplplot -L"/usr/lib64" -ltcl -L"/usr/lib64" -ltk plplot-tcl.pc:libdir=/usr/lib64 plplot-tcl.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-tcl.pc:Libs.private: -L"${libdir}" -lplplot -ltclmatrix -L"/usr/lib64" -ltcl -L"/usr/lib64" -ltk plplot-wxwidgets.pc:libdir=/usr/lib64 plplot-wxwidgets.pc:drvdir=/usr/lib64/plplot5.11.0/drivers plplot-wxwidgets.pc:Libs.private: -L"${libdir}" -lplplot -lplplotcxx -pthread -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L"/usr/lib64" -lwx_baseu-2.8 -L"/usr/lib64" -lwx_gtk2u_core-2.8 plplot-wxwidgets.pc:Cflags: -I"${includedir}" -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 But I can set CMAKE_INSTALL_PKG_CONFIG_DIR if absolutely necessary. Debian appears to use: /usr/lib/i386-linux-gnu/pkgconfig /usr/lib/x86_64-linux-gnu/pkgconfig So this change is almost certainly incorrect. > > Patch2b: RPATH > > Use -DUSE_RPATH=OFF. This should make all rpath results empty and the > RPATH part of Patch2 redundant. > > @Orion: > In sum, with commit id 2b4e397 and the long-implemented USE_RPATH there > should no longer be any need for Patch2. Please confirm that. In the Makefiles I get: PKG_CONFIG_ENV = PKG_CONFIG_PATH="/usr/share/pkgconfig::/usr/lib64/pkgconfig:/usr/share/pkgconfig" RPATHCMD = So RPATHCMD looks mostly okay, however: ocaml/Makefile:RPATHCMD = -ccopt '' Is that right? But PKG_CONFIG_ENV still contains arch specific info. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel