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

Reply via email to