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" <[email protected]> > To: <[email protected]> > 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 > >> [email protected] www.bluequartz.net > >> > >> On Jun 5, 2013, at 8:24 AM, Pedro Vicente <[email protected]> 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. > >> > [email protected] > >> > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > >> > >> _______________________________________________ > >> Hdf-forum is for HDF software users discussion. > >> [email protected] > >> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > > > > _______________________________________________ > > Hdf-forum is for HDF software users discussion. > > [email protected] > > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > > > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
