PLplot

On Wed, 29 Aug 2012 06:45:08 -0700 (PDT)
  phil rosenberg <philip_rosenberg@...> wrote:

...

> Secondly, when I try to build the examples in release 
>mode i get problems with undefined symobls to do with 
>wxAssert. As you might expect these calls are all inside 
>#ifdefs and should only be called in debug mode. So it 
>appears that somewhere _DEBUG or __wxDEBUG__ is being 
>defined in the release build.
>  

Have you checked the .vcproj files for occurrences of
_DEBUG or __wxDEBUG__? That might give you a clue as to
where this is coming from. Unfortunately, each one will
have that symbol for the Debug configuration, so it is
a bit of a pain.

(__wxDEBUG__ ought to exist in only a very small number of
files)

Regards,

Arjen


 

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.

I think I've found the problem, but haven't properly solved it.
 
I am using -DCMAKE_CXX_FLAGS_RELEASE="/MT" and -DCMAKE_CXX_FLAGS_DEBUG="/MTd" and the C versions of these flags to specify static linkage. I found that adding /DNDEBUG to the release versions of the flags cured my problem.
 
However I've also recently tried building with unicode enabled, but using -DCMAKE_CXX_FLAGS="/D UNICODE /D _UNICODE". this caused me build errors that I narrowed down to not having WIN32 defined!
 
It seems that defining these flags on the command line is overriding the "normal" linker flags rather than adding to them. am I doing something wrong and is there a better way to do this?
 
Phil
 

________________________________
 From: Arjen Markus <arjen.markus@...>
To: phil rosenberg <philip_rosenberg@...>; "plplot-devel@..." <plplot-devel@...> 
Sent: Wednesday, 29 August 2012, 14:54
Subject: Re: [Plplot-devel] Building examples on Windows
  
On Wed, 29 Aug 2012 06:45:08 -0700 (PDT)
phil rosenberg <philip_rosenberg@...> wrote:

...

> Secondly, when I try to build the examples in release mode i get problems with undefined symobls to do with wxAssert. As you might expect these calls are all inside #ifdefs and should only be called in debug mode. So it appears that somewhere _DEBUG or __wxDEBUG__ is being defined in the release build.
>  

Have you checked the .vcproj files for occurrences of
_DEBUG or __wxDEBUG__? That might give you a clue as to
where this is coming from. Unfortunately, each one will
have that symbol for the Debug configuration, so it is
a bit of a pain.

(__wxDEBUG__ ought to exist in only a very small number of
files)

Regards,

Arjen




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.

Hi Phil,

it is probably better to append these flags to the existing values
rather than resetting them. But my somewhat limited knowledge of CMake
does not allow me to immediately come up with the proper sequence of
commands.

Regards,

Arjen

On 2012-08-31 16:04, phil rosenberg wrote:
> I think I've found the problem, but haven't properly solved it.
>  
> I am using -DCMAKE_CXX_FLAGS_RELEASE="/MT" and 
> -DCMAKE_CXX_FLAGS_DEBUG="/MTd" and the C versions of these flags to 
> specify static linkage. I found that adding /DNDEBUG to the release 
> versions of the flags cured my problem.
>  
> However I've also recently tried building with unicode enabled, 
> but using -DCMAKE_CXX_FLAGS="/D UNICODE /D _UNICODE". this caused me 
> build errors that I narrowed down to not having WIN32 defined!
>  
> It seems that defining these flags on the command line is overriding the 
> "normal" linker flags rather than adding to them. am I doing something 
> wrong and is there a better way to do this?
>  
> Phil
> 
> *From:* Arjen Markus <arjen.markus@...>
> *To:* phil rosenberg <philip_rosenberg@...>; 
> "plplot-devel@..." <plplot-devel@...>
> *Sent:* Wednesday, 29 August 2012, 14:54
> *Subject:* Re: [Plplot-devel] Building examples on Windows
> 
> On Wed, 29 Aug 2012 06:45:08 -0700 (PDT)
> phil rosenberg <philip_rosenberg@... 
> <mailto:philip_rosenberg@...>> wrote:
> 
> ...
> 
>  > Secondly, when I try to build the examples in release mode i get 
> problems with undefined symobls to do with wxAssert. As you might expect 
> these calls are all inside #ifdefs and should only be called in debug 
> mode. So it appears that somewhere _DEBUG or __wxDEBUG__ is being 
> defined in the release build.
>  >  
> 
> Have you checked the .vcproj files for occurrences of
> _DEBUG or __wxDEBUG__? That might give you a clue as to
> where this is coming from. Unfortunately, each one will
> have that symbol for the Debug configuration, so it is
> a bit of a pain.
> 
> (__wxDEBUG__ ought to exist in only a very small number of
> files)
> 
> Regards,
> 
> Arjen
> 
> 
> 
> 
> 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.
> 
> 
> 
> 
> 
> 

 

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.

On 2012-08-31 07:04-0700 phil rosenberg wrote:

> I think I've found the problem, but haven't properly solved it.
>  
> I am using -DCMAKE_CXX_FLAGS_RELEASE="/MT" and -DCMAKE_CXX_FLAGS_DEBUG="/MTd" and the C versions of these flags to specify static linkage. I found that adding /DNDEBUG to the release versions of the flags cured my problem.
>  
> However I've also recently tried building with unicode enabled, but using -DCMAKE_CXX_FLAGS="/D UNICODE /D _UNICODE". this caused me build errors that I narrowed down to not having WIN32 defined!
>  
> It seems that defining these flags on the command line is overriding the "normal" linker flags rather than adding to them. am I doing something wrong and is there a better way to do this?

Hi Phil:

I never bother with the CMake CMAKE_BUILD_TYPE flag or set
CMAKE_<LANG>_FLAGS_<CONFIG> CMake options, where CONFIG is RELEASE,
DEBUG, etc.  But perhaps the problem is you should be using
CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE] (see documentation) to
specify linker flags?  Or you may have found a CMake bug
in how one (or some) of the CMAKE_<LANG>_FLAGS_<CONFIG> are implemented
so there is inappropriate leakage of the flag to the link step?

What always works for me is to use the default CMAKE_BUILD_TYPE and
simply set the environment variables CFLAGS, CXXFLAGS, and FFLAGS to
whatever I like for the current build

I am currently using

CXXFLAGS=-O3 -fvisibility=hidden
CFLAGS=-O3 -fvisibility=hidden
FFLAGS=-O3

with no problems.  But I often use something much more complicated or
something very simple.  However, I don't know how to set linker flags
with this environment variable approach.

With regard to your use case, if all you are concerned about is static
linking of the internal PLplot libraries and executables amongst
themselves, then setting -DBUILD_SHARED_LIBS=OFF will do the trick.
But that doesn't deal with the case of how PLplot libraries and
executables are linked with external libraries, and if you want that
linking to be static as well then you should look at the documentation
of the CMake target property LINK_SEARCH_START_STATIC.  You cannot set
target properties directly from the cmake command line, but if you
modify src/CMakeLists.txt files to set that target property for, say,
the plplotd library, and it works for you, then we could set up a
command-line option (called, say, EXTERNAL_STATIC_LINKING).  If the
user specifies that option as ON then we could change our current
build system so that wherever that system creates libraries or
executables, the CMake logic to set the corresponding target property
LINK_SEARCH_START_STATIC would also be executed.

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
__________________________

Hi Alan
Sorry to bump this, did you ever look at the patch I submitted for static runtime linkage? If you are happy with it then I can update the  MSVC++ build instructions on the wiki page.
 
Phil
 

________________________________
 From: phil rosenberg <philip_rosenberg@...>
To: Alan W. Irwin <irwin@...> 
Cc: Arjen Markus <arjen.markus@...>; "plplot-devel@..." <plplot-devel@...> 
Sent: Saturday, 1 September 2012, 0:23
Subject: Re: [Plplot-devel] Building examples on Windows
  

Hi Alan
Thanks for the suggestions. Using the environment variables seems to work for unicode, but not for the static linkage. When I refer to static linkage I mean linkage with the static/dynamic linked runtime library, rather than internal static linkage to generate a .lib rather than a .dll.
A bit more googling actually found this item
http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
I've basically taken that code snippet and added it to the cmakelists.txt file for the c/c++ examples, src, c++, wxwidgets, csa and qsastime directories. For csa and qsastime I had to change CXX_FLAGS to C_FLAGS, but doing this for the src and c examples actually stopped the change working in these cases - I'm not sure why. I've wrapped the changes in an if(STATIC_RUNTIME). I'm not sure if the code should be added anywhere else.
 
I've attached a patch so you can see exactly what I've done. Unfortunately I have no experience with writing CMAKE files so I'm not sure if I've added the code in a sensible place - but it works.
 
One other item I noticed. the qsastime and csa libraries don't get the tag appended. Is this by design? 
 
Phil
 

________________________________
 From: Alan W. Irwin <irwin@...>
To: phil rosenberg <philip_rosenberg@...> 
Cc: Arjen Markus <arjen.markus@...>; "plplot-devel@..." <plplot-devel@...> 
Sent: Friday, 31 August 2012, 19:47
Subject: Re: [Plplot-devel] Building examples on Windows
  
On 2012-08-31 07:04-0700 phil rosenberg wrote:

> I think I've found the problem, but haven't properly solved it.
>  
> I am using -DCMAKE_CXX_FLAGS_RELEASE="/MT" and -DCMAKE_CXX_FLAGS_DEBUG="/MTd" and the C versions of these flags to specify static linkage. I found that adding /DNDEBUG to the release versions of the flags cured my problem.
>  
> However I've also recently tried building with unicode enabled, but using -DCMAKE_CXX_FLAGS="/D UNICODE /D _UNICODE". this caused me build errors that I narrowed down to not having WIN32 defined!
>  
> It seems that defining these flags on the
 command line is overriding the "normal" linker flags rather than adding to them. am I doing something wrong and is there a better way to do this?

Hi Phil:

I never bother with the CMake CMAKE_BUILD_TYPE flag or set
CMAKE_<LANG>_FLAGS_<CONFIG> CMake options, where CONFIG is RELEASE,
DEBUG, etc.  But perhaps the problem is you should be using
CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE] (see documentation) to
specify linker flags?  Or you may have found a CMake bug
in how one (or some) of the CMAKE_<LANG>_FLAGS_<CONFIG> are implemented
so there is inappropriate leakage of the flag to the link step?

What always works for me is to use the default CMAKE_BUILD_TYPE and
simply set the environment variables CFLAGS, CXXFLAGS, and FFLAGS to
whatever I like for the current build

I am currently using

CXXFLAGS=-O3 -fvisibility=hidden
CFLAGS=-O3
 -fvisibility=hidden
FFLAGS=-O3

with no problems.  But I often use something much more complicated or
something very simple.  However, I don't know how to set linker flags
with this environment variable approach.

With regard to your use case, if all you are concerned about is static
linking of the internal PLplot libraries and executables amongst
themselves, then setting -DBUILD_SHARED_LIBS=OFF will do the trick.
But that doesn't deal with the case of how PLplot libraries and
executables are linked with external libraries, and if you want that
linking to be static as well then you should look at the documentation
of the CMake target property LINK_SEARCH_START_STATIC.  You cannot set
target properties directly from the cmake command line, but if you
modify src/CMakeLists.txt files to set that target property for, say,
the plplotd library, and it works for you, then we could set up
 a
command-line option (called, say, EXTERNAL_STATIC_LINKING).  If the
user specifies that option as ON then we could change our current
build system so that wherever that system creates libraries or
executables, the CMake logic to set the corresponding target property
LINK_SEARCH_START_STATIC would also be executed.

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
__________________________

On 2012-09-29 06:46-0700 phil rosenberg wrote:

> Hi Alan
> Sorry to bump this, did you ever look at the patch I submitted for static runtime linkage? If you are happy with it then I can update the  MSVC++ build instructions on the wiki page.

Hi Phil:

I have no problem with anyone reminding us of stuff that is in danger
of getting lost on the mailing list.

I don't recall exactly what happened in this case, but probably I just
silently left it to Arjen to deal with since he is in a good position
to test your patch on the Windows platform.

Arjen, if you haven't dealt with this already, would
you be willing to take a look?

Alan
>
>
> ________________________________
> From: phil rosenberg <philip_rosenberg@...>
> To: Alan W. Irwin <irwin@...>
> Cc: Arjen Markus <arjen.markus@...>; "plplot-devel@..." <plplot-devel@...>
> Sent: Saturday, 1 September 2012, 0:23
> Subject: Re: [Plplot-devel] Building examples on Windows
>
>
> Hi Alan
> Thanks for the suggestions. Using the environment variables seems to work for unicode, but not for the static linkage. When I refer to static linkage I mean linkage with the static/dynamic linked runtime library, rather than internal static linkage to generate a .lib rather than a .dll.
> A bit more googling actually found this item
> http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
> I've basically taken that code snippet and added it to the cmakelists.txt file for the c/c++ examples, src, c++, wxwidgets, csa and qsastime directories. For csa and qsastime I had to change CXX_FLAGS to C_FLAGS, but doing this for the src and c examples actually stopped the change working in these cases - I'm not sure why. I've wrapped the changes in an if(STATIC_RUNTIME). I'm not sure if the code should be added anywhere else.
>  
> I've attached a patch so you can see exactly what I've done. Unfortunately I have no experience with writing CMAKE files so I'm not sure if I've added the code in a sensible place - but it works.
>  
> One other item I noticed. the qsastime and csa libraries don't get the tag appended. Is this by design? 
>  
> Phil
>
>
> ________________________________
> From: Alan W. Irwin <irwin@...>
> To: phil rosenberg <philip_rosenberg@...>
> Cc: Arjen Markus <arjen.markus@...>; "plplot-devel@..." <plplot-devel@...>
> Sent: Friday, 31 August 2012, 19:47
> Subject: Re: [Plplot-devel] Building examples on Windows
>
> On 2012-08-31 07:04-0700 phil rosenberg wrote:
>
>> I think I've found the problem, but haven't properly solved it.
>>  
>> I am using -DCMAKE_CXX_FLAGS_RELEASE="/MT" and -DCMAKE_CXX_FLAGS_DEBUG="/MTd" and the C versions of these flags to specify static linkage. I found that adding /DNDEBUG to the release versions of the flags cured my problem.
>>  
>> However I've also recently tried building with unicode enabled, but using -DCMAKE_CXX_FLAGS="/D UNICODE /D _UNICODE". this caused me build errors that I narrowed down to not having WIN32 defined!
>>  
>> It seems that defining these flags on the
> command line is overriding the "normal" linker flags rather than adding to them. am I doing something wrong and is there a better way to do this?
>
> Hi Phil:
>
> I never bother with the CMake CMAKE_BUILD_TYPE flag or set
> CMAKE_<LANG>_FLAGS_<CONFIG> CMake options, where CONFIG is RELEASE,
> DEBUG, etc.  But perhaps the problem is you should be using
> CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE] (see documentation) to
> specify linker flags?  Or you may have found a CMake bug
> in how one (or some) of the CMAKE_<LANG>_FLAGS_<CONFIG> are implemented
> so there is inappropriate leakage of the flag to the link step?
>
> What always works for me is to use the default CMAKE_BUILD_TYPE and
> simply set the environment variables CFLAGS, CXXFLAGS, and FFLAGS to
> whatever I like for the current build
>
> I am currently using
>
> CXXFLAGS=-O3 -fvisibility=hidden
> CFLAGS=-O3
> -fvisibility=hidden
> FFLAGS=-O3
>
> with no problems.  But I often use something much more complicated or
> something very simple.  However, I don't know how to set linker flags
> with this environment variable approach.
>
> With regard to your use case, if all you are concerned about is static
> linking of the internal PLplot libraries and executables amongst
> themselves, then setting -DBUILD_SHARED_LIBS=OFF will do the trick.
> But that doesn't deal with the case of how PLplot libraries and
> executables are linked with external libraries, and if you want that
> linking to be static as well then you should look at the documentation
> of the CMake target property LINK_SEARCH_START_STATIC.  You cannot set
> target properties directly from the cmake command line, but if you
> modify src/CMakeLists.txt files to set that target property for, say,
> the plplotd library, and it works for you, then we could set up
> a
> command-line option (called, say, EXTERNAL_STATIC_LINKING).  If the
> user specifies that option as ON then we could change our current
> build system so that wherever that system creates libraries or
> executables, the CMake logic to set the corresponding target property
> LINK_SEARCH_START_STATIC would also be executed.
>
> 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
> __________________________

__________________________
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
__________________________

Hi Alan, Phil,

On Sat, 29 Sep 2012 16:53:17 -0700 (PDT)
  "Alan W. Irwin" <irwin@...> wrote:

> 
> I don't recall exactly what happened in this case, but 
>probably I just
> silently left it to Arjen to deal with since he is in a 
>good position
> to test your patch on the Windows platform.
> 
> Arjen, if you haven't dealt with this already, would
> you be willing to take a look?
> 

I do not recall the follow-up either, but I should be able
to look into this. I will try to do that this week.

Regards,

Arjen

 

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.

Hi Phil, Alan,

just tested this on Windows, using MS VC/C++ 2008 and GCC (MinGW)
with CMake 2.8.7:

With the option BUILD_SHARED_LIBS=OFF, the build process results
in static libraries (for PLplot, csirocsa and qsastime, the default
libraries that are usually built on my system).

The only dynamic libraries left are the runtime libraries that
come from the compiler.

So it is not necessary to apply Phil's patch anymore. (The problems
may have been due to some bug/quirk in older CMake versions.)

Regards,

Arjen

On 2012-10-01 09:50, Arjen Markus wrote:
> Hi Alan, Phil,
> 
> On Sat, 29 Sep 2012 16:53:17 -0700 (PDT)
>   "Alan W. Irwin" <irwin@...> wrote:
> 
>> I don't recall exactly what happened in this case, but 
>> probably I just
>> silently left it to Arjen to deal with since he is in a 
>> good position
>> to test your patch on the Windows platform.
>>
>> Arjen, if you haven't dealt with this already, would
>> you be willing to take a look?
>>
> 
> I do not recall the follow-up either, but I should be able
> to look into this. I will try to do that this week.
> 
> Regards,
> 
> Arjen
> 
>  
> 
> 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.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> 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.