On 2015-05-18 16:53-0600 Orion Poplawski wrote: > On 05/18/2015 01:35 AM, Alan W. Irwin wrote: [...] >> 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.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 [...]
OK. Thanks for reminding me that these *.pc files are arch-dependent. I don't know what I was thinking. But it also appears that Fedora and Debian disagree here concerning library install locations; Fedora uses /usr/lib or /usr/lib64 while Debian uses /usr/lib/i386-linux-gnu or /usr/lib/x86_64-linux-gnu. Currently, our CMake build system model sets the default library location with (in cmake/modules/instdirs/cmake) set( CMAKE_INSTALL_LIBDIR ${CMAKE_INSTALL_EXEC_PREFIX}/lib CACHE PATH "install location for object code libraries" ) Since that default satisfies neither Andrew's or your needs I assume you both have to override CMAKE_INSTALL_LIBDIR. In fact, Andrew (from debian/rules) overrides it with -DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) and I assume you have to do something similar in your spec file. Therefore, to make life more convenient for you both I have used set( CMAKE_INSTALL_PKG_CONFIG_DIR ${CMAKE_INSTALL_LIBDIR}/pkgconfig CACHE PATH "install location for pkg-config *.pc files" ) for the pkg-config default install directory in my latest commit (3062c3b). Which implies if you override CMAKE_INSTALL_LIBDIR, then CMAKE_INSTALL_PKG_CONFIG_DIR automatically gets overridden as well so you don't have to override it separately. So please try again with that commit to see if it satisfies your needs. > In the Makefiles I get: > [...] > ocaml/Makefile:RPATHCMD = -ccopt '' > > Is that right? Well, I double checked and that is indeed the expected result if -DUSE_RPATH=OFF. However, I don't comprehensively build- or run-test -DUSE_RPATH=OFF here (I have enough such testing on my plate already with default -DUSE_RPATH=ON), and instead leave such testing to distribution packagers who really do need -DUSE_RPATH=OFF. So really the definitive test of that result is do the ocaml examples build and run fine for you with that null string -ccopt option for the traditional build of installed examples or does the OCaml compiler choke on that null string? Run "make noninteractive >& noninteractive.out" in $prefix/share/plplot5.11.0/examples to find out. 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 __________________________ ------------------------------------------------------------------------------ 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