On 6/6/2013 1:42 AM, Pedro Vicente wrote:
Hey , Allen & Ward, next time I send an email to *both* of your group
lists, can you just do a "reply-all" ? :-) ... otherwise , we get half
of the answers.
Building NetCDF statically isalready an option, by passing
-DBUILD_SHARED_LIBS=OFF during configuration.
This will build the netcdf libraries andutilities statically, avoiding the
direct dependency on MSVCR100.dll.
They will, however, still inherit any downstream .dll dependenciesfrom the
curl, hdf and zlib libraries.
Exactly, Ward, netCDF inherits HDF, that 's why I am bugging Allen here :-)
And, yes, the solution is to build *all* downstream code in the *same*
way, either all static or all dynamic;
mixing both will get you linking errors.
You might be able to work aroundthis by downloading (or building) static
versions of these libraries.
Yes, Ward, this can be done by editing the HDF Cmake generated VS
projects, and changing all of them to static, which I just did.
In the curl case, you can do this by editing the file MakefileBuild.vc
and change all /MD (dynamic) to /MT (static)
Runtime library configuration
!IF "$(RTLIBCFG)"=="static"
#RTLIB = /MT
RTLIB = /MTd
RTLIB_DEBUG = /MTd
!ELSE
#RTLIB = /MD
#RTLIB_DEBUG = /MDd
Our binaries redistribute the MSCRT dlls that are used to build the binaries.
Hey, Allen, I was not asking for the *binaries* !
I was asking for an *option* in your CMake system that allows
anyone who wants to generate the Visual Studio projects have them
*already* "static ready" if they wish...
You could set CMAKE_C_FLAGS_RELEASE to "/MT /O2 /Ob2 /D NDEBUG" (or
whatever your project requires) when generating the Visual Studio
projects with CMake.
Christoph
So that, next time I need to generate everything from scratch I don't
have to go each to each one of them (50 + projects ) and click the
static button 50 times ...
Because of the danger of usingdifferent CRTs (HDF lib uses one and user
program uses differentone) and the possible memory corruption with
allocations, we buildwith /MD and provide the CRT with our binary.
I don't pretend to know everything, but when I don't (often :-) ) I search
read this
http://stackoverflow.com/questions/14749662/microsoft-visual-studio-c-c-runtime-library-static-dynamic-linking
quote
" i personally prefer statically linked. i hate scrambling around
looking for the right redist/dll/etc."
that's what I do, I set to all static , and then move on to do more
interesting things, like writing software, than dealing with DLL
idiosyncracies.
quote
"Using /MT is risky if you create DLLs as well as an EXE. You'll end up
with multiple copies of the CRT in your program.
This was especially a problem with earlier versions of VS where each CRT
would get its own heap, "
Was this the problem you meant ?
This might be true if you are distributing *binaries* with both the EXE
and DLL. Or if you are linking your code against a 3rd party library
*without* the code,
someone gave you a LIB and a DLL only.
In the HDF, netCDF and NCO worlds none of this is true: all sources are
available , no secrets here :-)
And you are lucky, Allen , because you only have the downstream ZLIB,
and netCDF only has curl
Here's a list of all NCO dependencies
zlib ,
HDF5,
curl,
netCDF, including OpenDAP, thank you for that :-)
ANTLR, a parser generator for ncap2
GSL, the GNU scientific library
UDUnits, Unidata units (Not yet available for Windows)
Regular Expressions (Not yet available for Windows, tough one this one )
I have Visual Studio projects for all these (except UDUnits and Regular
Expressions)
, because I need to build the *source* , as you can see many projects
to change to static/dynamic/32/64bit/debug/release combinations :-)
Pedro
------
Pedro Vicente, Earth System Science
University of California, Irvine
http://www.ess.uci.edu/
----- Original Message -----
From: "Allen Byrne" <byrn@xxxxxxxxxxxx <mailto:byrn@xxxxxxxxxxxx>>
To: <hdf-forum@xxxxxxxxxxxxxxxxxx <mailto:hdf-forum@xxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, June 05, 2013 6:18 AM
Subject: Re: [Hdf-forum] Make the Cmake Windows build static please !
Our binaries redistribute the MS CRT dlls that areused to build the binaries.
Because of the danger of using differentCRTs (HDF lib uses one and user
program uses different one) and thepossible memory corruption with
allocations, we build with /MD andprovide the CRT with our binary.
Hopefully, as more people useCMake and build a common knowledge of using
CMake, those wishing tobuild alternative versions of HDF will share their
codechanges.
Allen
On Wednesday, June 05,2013 09:34:37 AM Michael Jackson wrote:
Funny, I actually _prefer_the DLL builds because I distribute the runtime
C/C++ libraries asallowed by MS. Depending on how one is using the HDF5
executables/libraries having each library linked statically against their
own C/C++ libraries can also lead to problems because of howmemory is
allocated/deallocated in each library version. There are 2evils here and
the idea is to pick the least of them. If anything Iwould petition the
HDFGroup to provide BOTH a dynamically linked ANDa statically linked
runtime version.
Justmy 2 cents. Then again, I build my own HDF5 for our project precisely
because of issues like this.
___________________________________________________________
MikeJackson Principal Software Engineer
BlueQuartzSoftware Dayton, Ohio
mike.jackson@xxxxxxxxxxxxxx <mailto:mike.jackson@xxxxxxxxxxxxxx>
www.bluequartz.net <http://www.bluequartz.net>
On Jun 5, 2013, at 8:24 AM, PedroVicente <pvicente@xxxxxxx
<mailto:pvicente@xxxxxxx>> wrote:
> Hi Allen, Ward
>
> I have a request regarding your new CMake Windows buildsystem, could you
> add an option to make the build staticregarding the Microsoft libraries
> (MSVCR100D.dll) ?
>
> Starting with version 4.3.1, NCO
>
>http://nco.sourceforge.net/
>
> uses the HDF5 and netCDFWindows libraries made with your CMake system,
> and this iscausing problems for NCO users, as explained here
>
> https://sourceforge.net/projects/nco/forums/forum/9830/topic/8345151
>
> and here
>
>https://sourceforge.net/projects/nco/forums/forum/9829/topic/8417103
>
>
> This isjust a matter of changing the compiler flag to /MT(d)
>
>http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
>
> Using a dynamic build isjust a bad idea, because of these DLL issues.
>
>I have some Windows executables from code I did in the early 90's , that
> unfortunately I cannot run today, just because I linkedthem with DLLs,
> with the DLLs from the Visual Studio from thattime, that do not exist
> anymore (it seems every new versionthey change the Visual Studio Dlls).
>
> Becauseof this I do not use Dlls, I know that eventually something will
> go wrong :-)
>
> Pedro
>
> ------
> Pedro Vicente, Earth SystemScience
> University of California, Irvine
>http://www.ess.uci.edu/
>
>
>_______________________________________________
> Hdf-forum isfor HDF software users discussion.
>Hdf-forum@xxxxxxxxxxxxxxxxxx <mailto:Hdf-forum@xxxxxxxxxxxxxxxxxx>
>http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
_______________________________________________
Hdf-forum is for HDFsoftware users discussion.
Hdf-forum@xxxxxxxxxxxxxxxxxx <mailto:Hdf-forum@xxxxxxxxxxxxxxxxxx>
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
_______________________________________________
Hdf-forum is for HDFsoftware users discussion.
Hdf-forum@xxxxxxxxxxxxxxxxxx <mailto:Hdf-forum@xxxxxxxxxxxxxxxxxx>
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
