Re: [Plplot-devel] Your recent update to README.developers concerning workflow
Hi everyone, I am trying to push some small changes onto the official repository, using the workflow as documented in the README, but for some reason it fails: D:\plplot-svn\plplot-plplot [master]> git push --dry-run origin master fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. My guess is that this has to do with the user ID that git uses on my machine versus the user ID on SourceForge that it should use, but I do not know how to change it. Can anyone help here? (I applied the user.name and user.email commands, but these are not relevant for this issue) Regards, Arjen > -Original Message- > From: Hazen Babcock [mailto:hbabc...@mac.com] > Sent: Thursday, August 28, 2014 1:13 PM > To: Alan W. Irwin; PLplot development list > Subject: Re: [Plplot-devel] Your recent update to README.developers concerning > workflow > > On 8/27/2014 12:09 AM, Alan W. Irwin wrote: > > Here are some questions concerning git capabilities and our current > > workflow that you have documented in README.developers. > > > > Do you think it would be a good idea to change all the "git merge" > > commands in your workflow documentation to use the --ff-only option? > > That is use > > > > git merge --ff-only origin/master > > > > early in your workflow documentation and > > > > git merge --ff-only new_branch > > > > later in that documentation? > > I added this. > > > And if you like that idea, is there a better way to implement ff-only > > (say with a git config option that applies just to our repo)? > > And this, thanks for the suggestions. > > -Hazen > > > -- > 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 DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- 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
Re: [Plplot-devel] tcl build problem
Hi Alan
I have cured the actual link errors - I was trying to link 64 bit tcl libraries
into 32 bit plplot examples - obviously it didn't work.
The only real issue left is the appended .lib outside the quotes. I can't find
if that is something that we do or something that CMake does. I expected to
find a TARGET_LINK_LIBRARIES call with either items from DRIVERS_LINK_FLAGS or
ntk_LINK_FLAGS somewhere, but I can't find it.
Phil
From: phil rosenberg
To: Alan W. Irwin
Cc: PLplot development list
Sent: Friday, 29 August 2014, 0:18
Subject: Re: [Plplot-devel] tcl build problem
Hi Alan
I found the same location in the file you specified between checking emails. I
have been through and added the \" where appropriate to the various (rpath,
compile, linker) flags. This allows me to compile, but I am getting linker
errors in the examples, because the linker flags are ending up as
"C:/Program Files/Tcl/lib/tcl86.lib".lib
I'm not sure where the extra .lib is appearing from. If I fix this manually I
then get further linker errors which seem to be name decoration static vs
dynamic library issues. I will have to figure those out on my system.
From: Alan W. Irwin
To: Phil Rosenberg
Cc: PLplot development list
Sent: Thursday, 28 August 2014, 21:29
Subject: RE: [Plplot-devel] tcl build problem
On 2014-08-28 20:33+0100 Phil Rosenberg wrote:
> Hi Alan
> Given what you said I did a quick google for cmake paths spaces and
immediately found this post
http://stackoverflow.com/questions/9964775/using-cmakes-include-directories-command-with-white-spaces.
Seems the issue is the same there and is a result of the find modules
assuming no whitespace. I'll see if I can work out where the
quotes
should go and if not then I'll uninstall and reinstall tcl I guess.
Hi Phil:
I mostly agree with everything I read at that stackoverflow site but
compile flags are a special case where the result must be a blank
delimited string (as opposed to a CMake list).
Looking further (in cmake/modules/tk.cmake) the culprit appears to be
the command
set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}")
(where it just happens -I${TCL_INCLUDE_PATH} and
${TKLIB_COMPILE_FLAGS} refer to the same thing on your system, but on
other systems they can be different and the repeat duplicate -I
options should not be an issue on your system.
When faced with CMake logic issues, it is always a good
idea to make a few-line file to test out possibilities.
In this case my test file (test.cmake) reads
# Note the quotes which keep TCL_INCLUDE_PATH and TKLIB_COMPILE_FLAGS
# from
being lists. I think these represent the CMake variables
# exactly on your system.
set(TCL_INCLUDE_PATH "C:/Program Files/Tcl/include")
set(TKLIB_COMPILE_FLAGS "-IC:/Program Files/Tcl/include")
#Wrong (as currently the case in cmake/modules/tk.cmake)
set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}")
message(STATUS "wrong ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}")
#Right (I hope)
set(ntk_COMPILE_FLAGS "\"-I${TCL_INCLUDE_PATH}\" \"${TKLIB_COMPILE_FLAGS}\"")
message(STATUS "right ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}")
and you run it like this:
irwin@raven> cmake -P test.cmake
-- wrong ntk_COMPILE_FLAGS = -IC:/Program Files/Tcl/include -IC:/Program
Files/Tcl/include
-- right ntk_COMPILE_FLAGS = "-IC:/Program Files/Tcl/include" "-IC:/Program
Files/Tcl/include"
I suggest you change cmake/modules/tk.cmake to
conform to the second
form, and then observe (via the VERBOSE=1 option on nmake) the
resulting build command. My hope is that one string with
blank-separated entities that are themselves quoted using escaped
quotes (the "right" version above) will force CMake to generate
compile options of either
"-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include"
or
-IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include
But let me know what the VERBOSE=1 nmake option tells you
about the actual build command that results from the above
change.
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
Re: [Plplot-devel] Your recent update to README.developers concerning workflow
> From: Arjen Markus > Subject: Re: [Plplot-devel] Your recent update to README.developers > concerning workflow > To: PLplot development list > Message-ID: > <8CF085736108634681FD03EC36E6A0720E6A4FC7@V-EXC-C02.DIRECTORY.INTRA> > Content-Type: text/plain; charset="us-ascii" > > Hi everyone, > > > > I am trying to push some small changes onto the official repository, using > the workflow as documented in the README, but for some reason it fails: > > > > D:\plplot-svn\plplot-plplot [master]> git push --dry-run origin master > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > I think the problem is that you have the wrong repo URL. You need to first log in to the SF site and then use the new URL that you see called "developer access" or something instead of "read only access". You can change the URL or add another remote with the "git remote" command. I've no idea why they choose to make this strange distinction, it is not intrinsic to git. -Hazen -- 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
Re: [Plplot-devel] Your recent update to README.developers concerning workflow
Hi Hazen, That must have been the problem. I will try this "git remote" command. Thanks. Regards, Arjen > -Original Message- > From: Hazen Babcock [mailto:hbabc...@mac.com] > Sent: Friday, August 29, 2014 11:19 AM > To: plplot-devel@lists.sourceforge.net > Subject: Re: [Plplot-devel] Your recent update to README.developers concerning > workflow > > > From: Arjen Markus > > Subject: Re: [Plplot-devel] Your recent update to README.developers > > concerning workflow > > To: PLplot development list > > Message-ID: > > <8CF085736108634681FD03EC36E6A0720E6A4FC7@V-EXC- > C02.DIRECTORY.INTRA> > > Content-Type: text/plain; charset="us-ascii" > > > > Hi everyone, > > > > > > > > I am trying to push some small changes onto the official repository, using > > the > workflow as documented in the README, but for some reason it fails: > > > > > > > > D:\plplot-svn\plplot-plplot [master]> git push --dry-run origin master > > > > fatal: Could not read from remote repository. > > > > > > > > Please make sure you have the correct access rights > > > > and the repository exists. > > > > I think the problem is that you have the wrong repo URL. You need to first > log in to > the SF site and then use the new URL that you see called "developer access" or > something instead of "read only access". You can change the URL or add another > remote with the "git remote" command. I've no idea why they choose to make > this > strange distinction, it is not intrinsic to git. > > -Hazen > > > -- > 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 DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- 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
Re: [Plplot-devel] tcl build problem
On 2014-08-29 02:08-0700 phil rosenberg wrote:
> Hi Alan
> I have cured the actual link errors - I was trying to link 64 bit tcl
> libraries into 32 bit plplot examples - obviously it didn't work.
>
> The only real issue left is the appended .lib outside the quotes. I
can't find if that is something that we do or something that CMake
does. I expected to find a TARGET_LINK_LIBRARIES call with either
items from DRIVERS_LINK_FLAGS or ntk_LINK_FLAGS somewhere, but I can't
find it.
Hi Phil:
Because of your subscription concerns which I discussed with you off
list, I am going to send this to you twice as a test of your
subscription; once via the list and once only to you. So if you
get two duplicate e-mails you know all is well with your subscription.
That's excellent news that you whittled down all build system issues
for your MSVC platform to just one, the appended .lib. I would like
to google for that issue (in case it is a CMake bug rather than a
bug in our particular build system implementation). So I need to
know the exact CMake generator and MSVC version that you are using.
Also, if you are not currently using the -G"NMake Makefiles"
generator, I would switch to that one to see if the problem
disappears. And also switch to the latest CMake 2.8.x version which
is currently 2.8.12.2. The reason I suggest these two changes is that
the various Windows IDE generators are notoriously buggy compared to
the NMake generator, but 2.8.12.2 gives you the best chance of being
bug free amongst all the CMake-2.8.x alternatives. (Note that the
lastest stable CMake now is version 3.0.1, but our build system is not
really ready for CMake-3.0.x which is why I have suggested trying the
latest CMake in the 2.8.x.y series.)
With those preliminaries out of the way, it is now time to actually
answer your specific question above. :-)
ntk_LINK_FLAGS is used in the loop through all drivers that occurs in
drivers/CMakeLists.txt.
In that file, look for
if(ENABLE_DYNDRIVERS)
[...]
foreach(SOURCE_ROOT_NAME ${DRIVERS_LIST})
where DRIVERS_LIST includes ntk so later in
the logic ${SOURCE_ROOT_NAME}_LINK_FLAGS
corresponds to ntk_LINK_FLAGS. Thus, if you uncomment
#message("${SOURCE_ROOT_NAME}_LINK_FLAGS = ${${SOURCE_ROOT_NAME}_LINK_FLAGS}")
and
#message("${SOURCE_ROOT_NAME}_TARGETS = ${${SOURCE_ROOT_NAME}_TARGETS}")
those will help you to see what is going on. Also, later on in that
loop logic for the non-qt case you will see the following logic:
add_library(${SOURCE_ROOT_NAME} MODULE ${${SOURCE_ROOT_NAME}_SOURCE})
target_link_libraries(
${SOURCE_ROOT_NAME}
plplot${LIB_TAG}
${MATH_LIB}
${${SOURCE_ROOT_NAME}_LINK_FLAGS}
${${SOURCE_ROOT_NAME}_TARGETS}
)
Note, in this case ${SOURCE_ROOT_NAME}_LINK_FLAGS should be a CMake
list, i.e., output in message in the form "a;b;c" where a, b, and c
are the elements of the list that should get translated on the command
line (revealed by the VERBOSE=1 option) to a space-separated list of
linker options)
However, if your message output for ${SOURCE_ROOT_NAME}_LINK_FLAGS and
${SOURCE_ROOT_NAME}_TARGETS doesn't show anything peculiar, then my
bet is you are running into some kind of CMake bug for the particular
CMake version and generator that you are using which motivates my
suggestion above to move to the most bug-free version of CMake-2.8.x.y
as well as the NMake generator (which typically is more reliable than
any of the Windows IDE generators).
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
Re: [Plplot-devel] tcl build problem
Hi Alan
Got both your messages. Unfortunately that cannot be where the external
libraries are linked into the examples as I am building static libraries so
almost that entire file (including the section you indicated) is skipped.
Just to be clear, Plplot itself is building fine, the linker error is when
building the examples.
Phil
-Original Message-
From: "Alan W. Irwin"
Sent: 29/08/2014 17:16
To: "PLplot development list"
Subject: Re: [Plplot-devel] tcl build problem
On 2014-08-29 02:08-0700 phil rosenberg wrote:
> Hi Alan
> I have cured the actual link errors - I was trying to link 64 bit tcl
> libraries into 32 bit plplot examples - obviously it didn't work.
>
> The only real issue left is the appended .lib outside the quotes. I
can't find if that is something that we do or something that CMake
does. I expected to find a TARGET_LINK_LIBRARIES call with either
items from DRIVERS_LINK_FLAGS or ntk_LINK_FLAGS somewhere, but I can't
find it.
Hi Phil:
Because of your subscription concerns which I discussed with you off
list, I am going to send this to you twice as a test of your
subscription; once via the list and once only to you. So if you
get two duplicate e-mails you know all is well with your subscription.
That's excellent news that you whittled down all build system issues
for your MSVC platform to just one, the appended .lib. I would like
to google for that issue (in case it is a CMake bug rather than a
bug in our particular build system implementation). So I need to
know the exact CMake generator and MSVC version that you are using.
Also, if you are not currently using the -G"NMake Makefiles"
generator, I would switch to that one to see if the problem
disappears. And also switch to the latest CMake 2.8.x version which
is currently 2.8.12.2. The reason I suggest these two changes is that
the various Windows IDE generators are notoriously buggy compared to
the NMake generator, but 2.8.12.2 gives you the best chance of being
bug free amongst all the CMake-2.8.x alternatives. (Note that the
lastest stable CMake now is version 3.0.1, but our build system is not
really ready for CMake-3.0.x which is why I have suggested trying the
latest CMake in the 2.8.x.y series.)
With those preliminaries out of the way, it is now time to actually
answer your specific question above. :-)
ntk_LINK_FLAGS is used in the loop through all drivers that occurs in
drivers/CMakeLists.txt.
In that file, look for
if(ENABLE_DYNDRIVERS)
[...]
foreach(SOURCE_ROOT_NAME ${DRIVERS_LIST})
where DRIVERS_LIST includes ntk so later in
the logic ${SOURCE_ROOT_NAME}_LINK_FLAGS
corresponds to ntk_LINK_FLAGS. Thus, if you uncomment
#message("${SOURCE_ROOT_NAME}_LINK_FLAGS = ${${SOURCE_ROOT_NAME}_LINK_FLAGS}")
and
#message("${SOURCE_ROOT_NAME}_TARGETS = ${${SOURCE_ROOT_NAME}_TARGETS}")
those will help you to see what is going on. Also, later on in that
loop logic for the non-qt case you will see the following logic:
add_library(${SOURCE_ROOT_NAME} MODULE ${${SOURCE_ROOT_NAME}_SOURCE})
target_link_libraries(
${SOURCE_ROOT_NAME}
plplot${LIB_TAG}
${MATH_LIB}
${${SOURCE_ROOT_NAME}_LINK_FLAGS}
${${SOURCE_ROOT_NAME}_TARGETS}
)
Note, in this case ${SOURCE_ROOT_NAME}_LINK_FLAGS should be a CMake
list, i.e., output in message in the form "a;b;c" where a, b, and c
are the elements of the list that should get translated on the command
line (revealed by the VERBOSE=1 option) to a space-separated list of
linker options)
However, if your message output for ${SOURCE_ROOT_NAME}_LINK_FLAGS and
${SOURCE_ROOT_NAME}_TARGETS doesn't show anything peculiar, then my
bet is you are running into some kind of CMake bug for the particular
CMake version and generator that you are using which motivates my
suggestion above to move to the most bug-free version of CMake-2.8.x.y
as well as the NMake generator (which typically is more reliable than
any of the Windows IDE generators).
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
-
Re: [Plplot-devel] tcl build problem
On 2014-08-29 18:22+0100 Phil Rosenberg wrote:
> Hi Alan
> Got both your messages. Unfortunately that cannot be where the external
> libraries are linked into the examples as I am building static libraries so
> almost that entire file (including the section you indicated) is skipped.
> Just to be clear, Plplot itself is building fine, the linker error is when
> building the examples.
When the plplot library is built as a static library, the devices are
no longer independent DLL's, and instead the device code is inserted
into the plplot library so all device compile flags and link flags
need to be accumulated for that library. Of course, that is pretty
difficult to get all that implemented correctly because of the large
number of device drivers with many different dependencies so note my
remarks below about also testing the default shared plplot
library/dynamic devices case.
The relevant CMake logic for the static plplot library case is in
src/CMakeLists.txt (where the plplot library build is configured). In
that case look for
else(ENABLE_DYNDRIVERS)
list(APPEND libplplot${LIB_TAG}_LINK_LIBRARIES ${DRIVERS_LINK_FLAGS})
[...]
endif(ENABLE_DYNDRIVERS)
[...]
#message(STATUS
#"libplplot${LIB_TAG}_LINK_LIBRARIES =
${libplplot${LIB_TAG}_LINK_LIBRARIES}"
#)
target_link_libraries(
plplot${LIB_TAG}
${libplplot${LIB_TAG}_LINK_LIBRARIES}
)
You should uncomment that message command to look at the
CMake list in libplplot${LIB_TAG}_LINK_LIBRARIES to see if there is
anything strange there in the static libraries case. Of course, you
have stated that the static plplot library is building OK, but the
trouble you are having with example builds may originate in
how that library is built.
What you said before about the extra .lib issue was
'This allows me to compile, but I am getting linker errors in the
examples, because the
linker flags are ending up as
"C:/Program Files/Tcl/lib/tcl86.lib".lib'
To proceed further I need complete information. Therefore, please
send the usual that I always request for a complete bug report:
cmake version,
complete cmake options used,
complete output from cmake command starting from initially empty build tree,
complete (VERBOSE=1) output from (n)make command,
CMakeCache.txt file.
The first two items you can send just as part of the main text part of
your next post here, but the remaining items should be packed into a
compressed tarball or zip file and attached to that same post.
Here are some further possibilities to consider:
Use CMake-2.8.12.2 and the NMake generator (for the reasons I gave before).
Also, the static plplot library case is not nearly as well debugged
for our build system as the default shared libraries/dynamic devices
case. Therefore, I would also try that default case (which would be an
additional valuable test of building the Tcl/Tk bindings for your
platform). Of course, remember to use the -DTEST_DYNDRIVERS=OFF
workaround that is normally required for this case on Windows (to
avoid doing the simple test of dynamic devices that fails on Windows
when the same test with essentially the same code succeeds when run
from the plplot library on Windows! Go figure)
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
Re: [Plplot-devel] tcl build problem
Thanks Alan. I'll have a look at that over the weekend. But just so you know in
both the static and dynamic build case the libraries are not linked into the
plplot library. If I create a program and link in Plplot, then I must
separately link all the libraries that Plplot uses. This is the case also for
the examples. I can view the properties of each example project in visual
studio and see the libraries that are linked in - which is Plplot and all the
inherited dependencies. I'm not sure if this static behaviour is the same on
linux - it's obviously much less common to link statically on that OS.
Anyway. Have a good weekend.
Phil
-Original Message-
From: "Alan W. Irwin"
Sent: 29/08/2014 20:12
To: "Phil Rosenberg"
Cc: "PLplot development list"
Subject: RE: [Plplot-devel] tcl build problem
On 2014-08-29 18:22+0100 Phil Rosenberg wrote:
> Hi Alan
> Got both your messages. Unfortunately that cannot be where the external
> libraries are linked into the examples as I am building static libraries so
> almost that entire file (including the section you indicated) is skipped.
> Just to be clear, Plplot itself is building fine, the linker error is when
> building the examples.
When the plplot library is built as a static library, the devices are
no longer independent DLL's, and instead the device code is inserted
into the plplot library so all device compile flags and link flags
need to be accumulated for that library. Of course, that is pretty
difficult to get all that implemented correctly because of the large
number of device drivers with many different dependencies so note my
remarks below about also testing the default shared plplot
library/dynamic devices case.
The relevant CMake logic for the static plplot library case is in
src/CMakeLists.txt (where the plplot library build is configured). In
that case look for
else(ENABLE_DYNDRIVERS)
list(APPEND libplplot${LIB_TAG}_LINK_LIBRARIES ${DRIVERS_LINK_FLAGS})
[...]
endif(ENABLE_DYNDRIVERS)
[...]
#message(STATUS
#"libplplot${LIB_TAG}_LINK_LIBRARIES =
${libplplot${LIB_TAG}_LINK_LIBRARIES}"
#)
target_link_libraries(
plplot${LIB_TAG}
${libplplot${LIB_TAG}_LINK_LIBRARIES}
)
You should uncomment that message command to look at the
CMake list in libplplot${LIB_TAG}_LINK_LIBRARIES to see if there is
anything strange there in the static libraries case. Of course, you
have stated that the static plplot library is building OK, but the
trouble you are having with example builds may originate in
how that library is built.
What you said before about the extra .lib issue was
'This allows me to compile, but I am getting linker errors in the
examples, because the
linker flags are ending up as
"C:/Program Files/Tcl/lib/tcl86.lib".lib'
To proceed further I need complete information. Therefore, please
send the usual that I always request for a complete bug report:
cmake version,
complete cmake options used,
complete output from cmake command starting from initially empty build tree,
complete (VERBOSE=1) output from (n)make command,
CMakeCache.txt file.
The first two items you can send just as part of the main text part of
your next post here, but the remaining items should be packed into a
compressed tarball or zip file and attached to that same post.
Here are some further possibilities to consider:
Use CMake-2.8.12.2 and the NMake generator (for the reasons I gave before).
Also, the static plplot library case is not nearly as well debugged
for our build system as the default shared libraries/dynamic devices
case. Therefore, I would also try that default case (which would be an
additional valuable test of building the Tcl/Tk bindings for your
platform). Of course, remember to use the -DTEST_DYNDRIVERS=OFF
workaround that is normally required for this case on Windows (to
avoid doing the simple test of dynamic devices that fails on Windows
when the same test with essentially the same code succeeds when run
from the plplot library on Windows! Go figure)
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
Re: [Plplot-devel] tcl build problem
Hi Phil: On 2014-08-30 00:17+0100 Phil Rosenberg wrote: > Thanks Alan. I'll have a look at that over the weekend. But just so you know in both the static and dynamic build case the libraries are not linked into the plplot library. Yes, -DBUILD_SHARED_LIBS=ON or OFF (to use CMake terminology) either builds PLplot libraries as shared libraries and devices as independent shared DLL's or as static libraries (where the devices become part of the core library). But this CMake option says nothing at all about how external libraries are linked or whether the shared or static run time is used. > If I create a program and link in Plplot, then I must separately link all the libraries that Plplot uses. This is the case also for the examples. I can view the properties of each example project in visual studio and see the libraries that are linked in - which is Plplot and all the inherited dependencies. I'm not sure if this static behaviour is the same on linux - it's obviously much less common to link statically on that OS. There are three separate library linking issues. (1) linking PLplot libraries themselves (and only those libraries) as shared or static using BUILD_SHARED_LIBS to control that aspect; (2) linking external libraries (other than the run-time) as shared or static; and (3) using a shared or static run-time. On Linux and MinGW/MSYS/Wine I just take the default shared for (2) and (3) with no linking or run-time issues for both BUILD_SHARED_LIBS values. Of course, in the MinGW/MSYS/Wine case I have to be careful that the relevant external DLL's are on my PATH and similarly for the internal (PLplot) DLL's. Arjen's testing of Cygwin _and also_ MSVC with nmake has had similar success just using the default shared for (2) and (3). So I don't think you are going to run into trouble with MSVC and nmake by taking that same approach. If you look up the google terms you will see that typically users get into a world of hurt by attempting static versions of (2) and (3). Static (2) is tricky because, for example, all external static libraries have to be mentioned in the right order. Years ago I tried that with PLplot (with one of our ancient build systems) and eventually got it to work, but it was painful so I have never tried static (2) again because it was so much trouble. I think static (3) is easier, but I have never tried it because I don't see the point unless (2) is static as well. All of this is, of course, a side issue to that one remaining .lib.lib linking issue, but I hope your full bug report will help me figure out that issue. 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
