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 is already an option, by passing
>>-DBUILD_SHARED_LIBS=OFF during configuration.
>>This will build the netcdf libraries and utilities statically, avoiding the
>>direct dependency on MSVCR100.dll.
>>They will, however, still inherit any downstream .dll dependencies from 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 around this 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 MS CRT 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...
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 using different CRTs (HDF lib uses one and user
>>program uses different one) and the possible memory corruption with
>>allocations, we build with /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>
To: <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 are used to build the
> binaries.
> Because of the danger of using different CRTs (HDF lib uses one and user
> program uses different one) and the possible memory corruption with
> allocations, we build with /MD and provide the CRT with our binary.
>
> Hopefully, as more people use CMake and build a common knowledge of using
> CMake, those wishing to build alternative versions of HDF will share their
> code changes.
>
> 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 as allowed 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 how memory is
>> allocated/deallocated in each library version. There are 2 evils here and
>> the idea is to pick the least of them. If anything I would petition the
>> HDFGroup to provide BOTH a dynamically linked AND a statically linked
>> runtime version.
>>
>> Just my 2 cents. Then again, I build my own HDF5 for our project precisely
>> because of issues like this.
>> ___________________________________________________________
>> Mike Jackson Principal Software Engineer
>> BlueQuartz Software Dayton, Ohio
>> mike.jackson@xxxxxxxxxxxxxx www.bluequartz.net
>>
>> On Jun 5, 2013, at 8:24 AM, Pedro Vicente <pvicente@xxxxxxx> wrote:
>> > Hi Allen, Ward
>> >
>> > I have a request regarding your new CMake Windows build system, could you
>> > add an option to make the build static regarding the Microsoft libraries
>> > (MSVCR100D.dll) ?
>> >
>> > Starting with version 4.3.1, NCO
>> >
>> > http://nco.sourceforge.net/
>> >
>> > uses the HDF5 and netCDF Windows libraries made with your CMake system,
>> > and this is causing 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 is just a matter of changing the compiler flag to /MT(d)
>> >
>> > http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
>> >
>> > Using a dynamic build is just 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 linked them with DLLs,
>> > with the DLLs from the Visual Studio from that time, that do not exist
>> > anymore (it seems every new version they change the Visual Studio Dlls).
>> >
>> > Because of this I do not use Dlls, I know that eventually something will
>> > go wrong :-)
>> >
>> > Pedro
>> >
>> > ------
>> > Pedro Vicente, Earth System Science
>> > University of California, Irvine
>> > http://www.ess.uci.edu/
>> >
>> >
>> > _______________________________________________
>> > Hdf-forum is for HDF software users discussion.
>> > Hdf-forum@xxxxxxxxxxxxxxxxxx
>> > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> Hdf-forum@xxxxxxxxxxxxxxxxxx
>> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@xxxxxxxxxxxxxxxxxx
> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>
>
