+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 <pvicente@xxxxxxx> 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
>>
>>
>
> _______________________________________________
> netcdfgroup mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
