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...@nwra.com 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
