Menu
▾
▴
plplot-devel
|
From: Orion P. <or...@co...> - 2015-04-23 04:44:12
Attachments:
plplot-pkgconfig.patch
|
With plplot 5.10.0: # pkg-config plplotd --libs -lplplotd With plplot 5.11.0: -lplplot -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime # pkg-config plplot --libs This is wrong because the extra libraries are only necessary in the case of static linking. To indicate this use Libs.private. See also http://people.freedesktop.org/~dbn/pkg-config-guide.html The attached patch fixes. If some functions are referenced directly in the public plplot headers then you would need to add them to Libs. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
|
From: Alan W. I. <ir...@be...> - 2015-04-23 07:29:25
|
On 2015-04-22 22:44-0600 Orion Poplawski wrote: > With plplot 5.10.0: > > # pkg-config plplotd --libs > -lplplotd > > With plplot 5.11.0: > -lplplot -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime > > # pkg-config plplot --libs > > > This is wrong because the extra libraries are only necessary in the case of > static linking. Hi Orion: As always, thanks for your useful PLplot input from the Fedora perspective. Let me define some terminology here (used by CMake documentation) to clarify my comments below. Non-transitive linking of an executable or library occurs when you only specify the libraries to the linker are needed to resolve symbols directly in the executable or library that is being built. In contrast, transitive linking is when you mention not only those libraries, but also all libraries that are required to resolve all symbols throughout the hierachy of library links. The CMake documentation states that in all cases transitive linking should be used for the static case, and it is also safe to use that for the shared case but for platforms that support it, non-transitive linking can also be used for the shared library case. To summarize what you have found in this terminology, our pkg-config results (which, of course, have nothing to do with CMake other than we configure those *.pc files with our CMake-based build system) follow those rules for the static case, but for the shared case, 5.10.0 used non-transitive linking while 5.11.0 used transitive linking (which apparently Fedora complains about even though it is always safe to use transitive linking). > To indicate this use Libs.private. See also > http://people.freedesktop.org/~dbn/pkg-config-guide.html > > The attached patch fixes. If some functions are referenced directly in the > public plplot headers then you would need to add them to Libs. I just checked the two relevant *.pc files from 5.10.0 and 5.11.0, and they are the same other than dropping the "d" suffix. So the change in pkg-config result must not be due to something being done differently by PLplot. Instead, my guess is Fedora is likely doing something different now with pkg-config. For example, perhaps before they massaged pkg-config results but now they no longer do so more pkg-config transitive linking issues are revealed? That said, you are right (and actually the problem is likely more fundamental and pervasive then you have stated). I just checked, and for 5.11.0 and many prior versions, the pkg-config file for a PLplot library has been configured using the flag used to link to the library as well as all flags necessary to link the library itself, i.e., transitive linking from the point of view of some app trying to link to libplplot. For example, both the 5.10.0 plplotd.pc file and the 5.11.0 plplot.pc file mention the link flags -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime on the Libs: line and do not mention Libs.private at all. Therefore, there has been a long-term fundamental PLplot pkg-config issue for the shared linking case for platforms that support non-transitive linking. Another complication here is some platforms do not support non-transitive linking for the shared library case. For those, the user must specify the -DNON_TRANSITIVE=OFF cmake option, and that has to be propagated correctly to our configured pkg-config files so they use non-transitive linking for the shared case only when that is allowed by -DNON_TRANSITIVE=ON. Anyhow, I am virtually positive your patch involving Libs.private: will be part of the solution, but there is a lot to think about here and check before coming up with what I hope is the definitive solution for all the issues. And I plan to do that early in this release cycle after dealing with a bunch of other build-system issues that have recently come to my attention (i.e., moving CMP0022 and CMP0023 from OLD to NEW, moving CMP0026 from old to new, dealing with double linking issues for tcl-related libraries when ENABLE_DYNDRIVERS=OFF, and updating epa_build). 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 __________________________ |
|
From: Orion P. <or...@co...> - 2015-04-24 16:10:00
|
On 04/23/2015 01:29 AM, Alan W. Irwin wrote: > On 2015-04-22 22:44-0600 Orion Poplawski wrote: > >> With plplot 5.10.0: >> >> # pkg-config plplotd --libs >> -lplplotd >> >> With plplot 5.11.0: >> -lplplot -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime >> >> # pkg-config plplot --libs >> >> >> This is wrong because the extra libraries are only necessary in the case of >> static linking. > > Hi Orion: > > As always, thanks for your useful PLplot input from the Fedora > perspective. You know, someday I'd like to get a one line response from you :) > Let me define some terminology here (used by CMake documentation) to > clarify my comments below. Non-transitive linking of an executable or > library occurs when you only specify the libraries to the linker are > needed to resolve symbols directly in the executable or library that > is being built. In contrast, transitive linking is when you mention > not only those libraries, but also all libraries that are required to > resolve all symbols throughout the hierachy of library links. > > The CMake documentation states that in all cases transitive linking > should be used for the static case, and it is also safe to use that > for the shared case but for platforms that support it, non-transitive > linking can also be used for the shared library case. > > To summarize what you have found in this terminology, our pkg-config results > (which, > of course, have nothing to do with CMake other than we configure those > *.pc files with our CMake-based build system) follow those rules for the > static case, but for the shared case, 5.10.0 used non-transitive > linking while 5.11.0 used transitive linking (which apparently Fedora > complains about even though it is always safe to use transitive linking). Just to be clear, Fedora actively bans transitive linked for shared libraries. It leads to dependency bloat and other issues. >> To indicate this use Libs.private. See also >> http://people.freedesktop.org/~dbn/pkg-config-guide.html >> >> The attached patch fixes. If some functions are referenced directly in the >> public plplot headers then you would need to add them to Libs. > > I just checked the two relevant *.pc files from 5.10.0 and 5.11.0, and > they are the same other than dropping the "d" suffix. So the change in > pkg-config result must not be due to something being done differently > by PLplot. Instead, my guess is Fedora is likely doing something > different now with pkg-config. For example, perhaps before they > massaged pkg-config results but now they no longer do so more pkg-config > transitive linking issues are revealed? This is an incorrect assumption. While the *.pc.in files are the same, the way that you generate PC_LINK_FLAGS has obviously changed, and that is producing the final difference in the generated *.pc file. My F21 plplotd.pc file has: Libs: -L${libdir} -lplplotd > That said, you are right (and actually the problem is likely more > fundamental and pervasive then you have stated). I just checked, and > for 5.11.0 and many prior versions, the pkg-config file for a PLplot > library has been configured using the flag used to link to the library > as well as all flags necessary to link the library itself, i.e., > transitive linking from the point of view of some app trying to link > to libplplot. For example, both the 5.10.0 plplotd.pc file and the > 5.11.0 plplot.pc file mention the link flags -lltdl -lm -lshp > -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime on the Libs: line > and do not mention Libs.private at all. Therefore, there has been a > long-term fundamental PLplot pkg-config issue for the shared linking > case for platforms that support non-transitive linking. > > Another complication here is some platforms do not support > non-transitive linking for the shared library case. For those, the > user must specify the -DNON_TRANSITIVE=OFF cmake option, and > that has to be propagated correctly to our configured pkg-config > files so they use non-transitive linking for the shared case > only when that is allowed by -DNON_TRANSITIVE=ON. > > Anyhow, I am virtually positive your patch involving Libs.private: > will be part of the solution, but there is a lot to think about here > and check before coming up with what I hope is the definitive solution > for all the issues. And I plan to do that early in this release cycle > after dealing with a bunch of other build-system issues that have > recently come to my attention (i.e., moving CMP0022 and CMP0023 from > OLD to NEW, moving CMP0026 from old to new, dealing with double > linking issues for tcl-related libraries when ENABLE_DYNDRIVERS=OFF, > and updating epa_build). > > Alan Thanks as always for taking the time to look closely at this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 http://www.nwra.com |
|
From: Alan W. I. <ir...@be...> - 2015-04-25 01:59:03
|
On 2015-04-24 10:09-0600 Orion Poplawski wrote:
>> I just checked the two relevant *.pc files from 5.10.0 and 5.11.0, and
>> they are the same other than dropping the "d" suffix. So the change in
>> pkg-config result must not be due to something being done differently
>> by PLplot. Instead, my guess is Fedora is likely doing something
>> different now with pkg-config. For example, perhaps before they
>> massaged pkg-config results but now they no longer do so more pkg-config
>> transitive linking issues are revealed?
>
> This is an incorrect assumption. While the *.pc.in files are the same, the
> way that you generate PC_LINK_FLAGS has obviously changed
Likely not in the 5.11.0 release cycle. The above (identical) results
I refer to are for what is configured in 5.10.0 and what is configured
in 5.11.0 for the Libs: line in the *.pc files.
> producing the final difference in the generated *.pc file. My F21 plplotd.pc
> file has:
>
> Libs: -L${libdir} -lplplotd
I don't get that at all for 5.10.0. So it looks like you have found a
PLplot regression, but to confirm that here I need to know the exact
upstream version of PLplot where I should get the simple result for
the configured Libs: line. Or did you get that simple result because
of some downstream patch you applied?
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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2015-04-25 17:05:37
|
On 2015-04-25 09:59-0600 Orion Poplawski wrote:
> On 04/24/2015 07:58 PM, Alan W. Irwin wrote:
>> On 2015-04-24 10:09-0600 Orion Poplawski wrote:
[...]
>>> Libs: -L${libdir} -lplplotd
>>
>> I don't get that at all for 5.10.0.
>
> Ah, mea culpa, we had:
>
> # Fix pkgconfig libs
> # https://bugzilla.redhat.com/show_bug.cgi?id=998988
> Patch4: plplot-pkgconfig.patch
>
> diff -up plplot-5.9.9-svn12479/src/CMakeLists.txt.pkgconfig
> plplot-5.9.9-svn12479/src/CMakeLists.txt
> --- plplot-5.9.9-svn12479/src/CMakeLists.txt.pkgconfig 2013-07-09
> 13:27:35.000000000 -0600
> +++ plplot-5.9.9-svn12479/src/CMakeLists.txt 2013-08-23 10:17:31.522913437
> -0600
> @@ -472,7 +472,9 @@ if(PKG_CONFIG_EXECUTABLE)
> string(REGEX REPLACE "^.*:(.*):.*:.*$" "\\1" PC_SHORT_NAME ${PC_DATA})
> string(REGEX REPLACE "^.*:.*:(.*):.*$" "\\1" PC_LONG_NAME ${PC_DATA})
> string(REGEX REPLACE "^.*:.*:.*:(.*)$" "\\1" PC_LIBRARY_NAME ${PC_DATA})
> - set(PC_LINK_FLAGS "${lib${PC_LIBRARY_NAME}_LINK_FLAGS}")
> + if(NOT BUILD_SHARED_LIBS)
> + set(PC_LINK_FLAGS "${lib${PC_LIBRARY_NAME}_LINK_FLAGS}")
> + endif(NOT BUILD_SHARED_LIBS)
> set(PC_LINK_FLAGS "-l${PC_LIBRARY_NAME} ${PC_LINK_FLAGS}")
> set(PC_COMPILE_FLAGS "${lib${PC_LIBRARY_NAME}_COMPILE_FLAGS}")
> set(PC_CONFIGURED_FILE
Thanks for figuring that out.
Of course, once I get the general shared versus static linking issue
for PLplot pkg-config results fixed upstream, that downstream patch
will no longer be necessary.
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?
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
__________________________
|
|
From: Orion P. <or...@co...> - 2015-04-25 18:42:35
Attachments:
plplot-multiarch.patch
plplot-ocaml.patch
|
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. # Don't use -custom with ocamlc Patch7: plplot-ocaml.patch I've attached both. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
|
From: Alan W. I. <ir...@be...> - 2015-05-17 08:02:31
|
Hi Orion: In the last month or so you brought a number of linking issues for the traditional build system to my attention. I believe commit id = 6a5bad5 should fix those. Would you please run your traditional build tests on Fedora again to check that? Once you confirm all is well (i.e., no overlinking or underlinking) with the traditional build for this change, then I plan to deal with some of the other issues you brought up that did not involve the traditional build system. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2015-05-18 07:36:00
Attachments:
plplot-ocaml.patch
|
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. 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. > > # Don't use -custom with ocamlc > Patch7: plplot-ocaml.patch I have left that patch attached because I don't have any OCaml expertise to make an informed decision about whether to accept that upstream. Our OCaml go-to guy here was Hezekiah M. Carty so I have CC'd him in hopes that he will make the decision. @ Andrew: However, Hez has not been in contact for quite a while now so if he doesn't respond would you be willing to make the decision (since I believe your OCaml expertise no matter how small is still greater than my own. :-) ). 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 __________________________ |
|
From: Orion P. <or...@co...> - 2015-05-18 22:53:39
|
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...@nw...
Boulder, CO 80301 http://www.nwra.com
|
|
From: Orion P. <or...@co...> - 2015-05-18 23:04:54
|
On 05/17/2015 02:02 AM, Alan W. Irwin wrote:
> Hi Orion:
>
> In the last month or so you brought a number of linking issues for
> the traditional build system to my attention. I believe
> commit id = 6a5bad5 should fix those.
>
> Would you please run your traditional build tests on Fedora again to
> check that?
>
> Once you confirm all is well (i.e., no overlinking or underlinking)
> with the traditional build for this change, then I plan to deal with
> some of the other issues you brought up that did not involve the
> traditional build system.
>
> Alan
I suspect that some of these are unnecessary:
plplot-ada.pc:Libs: -L"${libdir}" -lplplotada -lplplot
Removing -lplplot still allows the ada examples to compile.
plplot-qt.pc:Libs: -L"${libdir}" -lplplotqt -L"/usr/lib64" -lQtSvg
-L"/usr/lib64" -lQtGui -L"/usr/lib64" -lQtCore
Interesting mix of -L"${libdir" and -L"/usr/lib64", but I suspect that comes
from the Qt stuff.
I don't seem to be getting Qt examples installed so I can't test.
Otherwise looks much better, thanks!
- Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nw...
Boulder, CO 80301 http://www.nwra.com
|
|
From: Alan W. I. <ir...@be...> - 2015-05-19 01:18:43
|
On 2015-05-18 17:04-0600 Orion Poplawski wrote:
> On 05/17/2015 02:02 AM, Alan W. Irwin wrote:
>> Hi Orion:
>>
>> In the last month or so you brought a number of linking issues for
>> the traditional build system to my attention. I believe
>> commit id = 6a5bad5 should fix those.
>>
>> Would you please run your traditional build tests on Fedora again to
>> check that?
>>
>> Once you confirm all is well (i.e., no overlinking or underlinking)
>> with the traditional build for this change, then I plan to deal with
>> some of the other issues you brought up that did not involve the
>> traditional build system.
>>
>> Alan
>
> I suspect that some of these are unnecessary:
>
> plplot-ada.pc:Libs: -L"${libdir}" -lplplotada -lplplot
>
> Removing -lplplot still allows the ada examples to compile.
Actually, that underlinks some of the examples (such as example 15) which have callbacks in
them which are implemented in Ada with direct calls to the C library
routines, e.g,
software@raven> nm --undefined examples/ada/x15a.o |grep c_
U c_plfill
and similarly for the other Ada examples with callbacks.
Here is the comment (in bindings/ada/CMakeLists.txt) from the CMake perspective:
# N.B. nm evidence shows that examples that use
# callbacks (e.g., plfill in x15a.adb) have unresolved references
# to c_plfill, etc. that require a public link to plplot
# regardless of how NON_TRANSITIVE is set.
target_link_libraries(plplotada PUBLIC plplot)
So I have just followed that CMake linking model for the traditional build
as well. Of course, I am no linking guru so if somebody here can give
convincing reasons why that CMake linking model is incorrect (i.e.,
reasons why I should ignore the above undefined reference to the C
version of the callback), then I would change both that model and the
pkg-config version of that model.
>
> plplot-qt.pc:Libs: -L"${libdir}" -lplplotqt -L"/usr/lib64" -lQtSvg
> -L"/usr/lib64" -lQtGui -L"/usr/lib64" -lQtCore
>
> Interesting mix of -L"${libdir" and -L"/usr/lib64", but I suspect that comes
> from the Qt stuff.
Exactly. So if you change your architecture the locations provided by
Qt should change consistently with how libdir changes.
> Otherwise looks much better, thanks!
And thank you for bringing up this topic. Our traditional build is a
whole lot stronger now as a result. See, for example, Arjen's recent
almost complete good test of the traditional build on Cygwin which has
never gotten as far before. So this is a nice example of the RedHat
Fedora community indirectly helping the RedHat Cygwin community, and
vice versa because some of the recent Cygwin PLplot fixes are general
ones that help all the Linux distros. After all these years, I still
like this cooperative development model the best.
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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2015-05-19 00:41:17
|
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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2015-05-19 01:23:16
|
On 2015-05-18 17:41-0700 Alan W. Irwin wrote: > [...]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. Gack! Of course, that should read make test_noninteractive >& test_noninteractive.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 __________________________ |
|
From: Orion P. <or...@co...> - 2015-05-27 18:23:12
|
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...@co...
Boulder, CO 80301 http://www.cora.nwra.com
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X