Hi Alan
I think we both are correct in terms of how libs are linked in both the Linux
and Windows world. However I am not entirely sure that on Windows CMake is
doing what you think it is doing.
Just so you know on Windows the additional libraries do not get linked into the
plplot library. However, when the examples are built, CMake remembers what the
additional libraries are and links them into the example executables. When I
want to link another executable with Plplot I have to link all the various
dependacies separately. This is the case with all versions of CMake I have ever
used. If this is the intended behaviour then all is fine - if not, then well it
still works so isn't a big deal I guess.
Re testing with the other settings. I will try - however it will be a very
minimal build as I only have static libs linked against the static runtime for
all the libraries I have built from source. I actually don't know how the Tcl
libraries were built as I downloaded a binary installer, so I'm not sure how
they will link.
Phil
________________________________
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: phil rosenberg <philip_rosenb...@yahoo.com>
Cc: Arjen Markus <arjen.mar...@deltares.nl>; PLplot development list
<plplot-devel@lists.sourceforge.net>
Sent: Sunday, 31 August 2014, 17:55
Subject: Re: [Plplot-devel] tcl build problem
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
__________________________
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
