All,
Support for /MT(d) was removed from CMake because we do not have resources to
support it with the HDF software (including HDF5).
If this is a desired feature, we will need someone to test it on a regular
basis (daily with development and release HDF5 branches). If there are
volunteers, please contact Allen. We will go from there.
Thank you!
Elena
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Elena Pourmal
Director of Technical Services and Operations
The HDF Group
1800 So. Oak St., Suite 203,
Champaign, IL 61820
www.hdfgroup.org
(217)531-6112 (office)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Jun 6, 2013, at 3: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 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
> >
> > _______________________________________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@xxxxxxxxxxxxxxxxxx
> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
