From: Alan W. I. <ir...@be...> - 2014-08-31 16:55:12
|
On 2014-08-31 00:37-0700 phil rosenberg wrote: > So on Windows either is acceptable - at least for static libs, dlls are a bit different. I can either link a library into a depending library then link this into my exe, or I can not link the libraries together and can link them all into the exe. Actually, I completely screwed up my explanation of transitive versus non-transitive linking. That consideration is only appropriate for the -DBUILD_SHARED_LIBS=ON case and is ignored in the -DBUILD_SHARED_LIBS=OFF case you were testing. Your remarks about static linking for Windows agree with what I think goes on for that case on Linux as well. My understanding is a static library on any platform is essentially just a collection of object code ready to be inserted into another library or else an executable _at link time_ (as opposed to being loaded at run time which is what happens with shared libraries). So if you link plplot with a static library, the relevant parts of that static library (those that satisfy some/all of plplot's of unresolved symbols) get inserted into the plplot library. So far so good, but if you forget to do that (which I think would generally be a poor choice), then the executable inherits those undefined symbols and you have one last chance to insert the static library's code into that executable. Note, that for the PLplot build system we have adopted the choice where target_link_libraries mentions _just_ the libraries that are needed because they satisfy unresolved symbols that are directly required by the particular library or executable being linked). So if a library or executable has a direct requirement we mention it but otherwise not. This should be perfect from the point of view of static libraries (as you have found) for CMake-3 or CMake-2.8.12.2. However, for the CMake-3 case there our warnings about the exact CMake code logic that enforces transitive versus non-transitive linking for the -DBUILD_SHARED_LIBS=ON case (but not -DBUILD_SHARED_LIBS=OFF) so for the -DBUILD_SHARED_LIBS=ON case I highly recommend you stick with cmake-2.8.12.2 which is known to give correct linking results with our current build system on Windows (and all other platforms). > [...]Thanks again for all your help Alan - sorry if my last email sounded a bit grumpy. You are welcome, and I also sometimes get grumpy at the "wild west" atmosphere of free software on Windows, but I think Cygwin and MinGW-w64/MSYS2 are turning that around. I saw your two commits on the git push feed, and I am about to test them on Linux both normally and also for the special case where I will create a blank-separated install path for the Tcl/Tk components. While I am doing that, would you be willing to test the default case (i.e., without -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON) for CMake-2.8.12.2 (see above) as well? Even a quick and dirty result with all PLplot components disabled that you find depend on the CMake-3 version of find modules would be worthwhile. I understand why for your personal use you like to use the above options and CMake-3's version of find modules, but a test without those options and with CMake-2.8.12.2 would be a big help from the point of view of nailing down some Tcl and blank-separated answers for the PLplot build system in the default case for your platform. 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 __________________________ |