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 [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
