+1 for " i personally prefer statically linked. i hate scrambling around looking for the right redist/dll/etc."
I'd call it hell [1] for novice users like me. :-) [1] http://en.wikipedia.org/wiki/DLL_Hell -- HDF: Software that Powers Science On Thu, Jun 6, 2013 at 3:42 AM, Pedro Vicente <[email protected]> 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 >> >> > > _______________________________________________ > netcdfgroup mailing list > [email protected] > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
