On 05/18/2015 06:41 PM, Alan W. Irwin wrote:
> 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.
Yup:
-DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \
> 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.
Interestingly (perhaps), the pkgconfig files were always installed properly
before without configuring - perhaps because it used pkg-config to determine
the location? I assume that's what should be done.
>
>> 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
> __________________________
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
