Michael
You do not need findHdf5 any more.
All you do is find_package(HDF5 NO_MODULE) and point hdf5 dir to where cmake
installed the hdf5-config.cmake (or whatever the file name is)
CMake defines all the targets as import/export definitions and everything is
done for you. There is simply no need to use find hdf5 if you have a cmake
install of it.
In your project you just say target_link_libraries(mytarget, hdf5 hdf5_hl etc
etc)
Cmake defines these targets for you when it imports the config.
You can install dozens of versions each with different names like
hdf5-1.8.11-static or anything and the name will be correctly picked up
(although we don't actually generate them yet so technically what I'm saying is
hypothetical!)
Throw away your findhdf5 file and move on with your life!
JB
-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of
Michael Jackson
Sent: 07 June 2013 14:39
To: HDF Users Discussion List
Cc: help@xxxxxxxxxxxx; netcdfgroup@xxxxxxxxxxxxxxxx
Subject: Re: [Hdf-forum] Make the Cmake Windows build static please !
Re: Version Stamp on library names. Please, do NOT do this. Boost does this and
trying to get a build system to find those libraries via wildcard searching is
fraught with danger and error prone. My FindHDF5.cmake file is crazy enough as
it is. Adding in the complication of looking for hdf5_1_8_10 OR blah blah blah
is going to make those Find modules even harder to write.
I do vote for the other idea though (static/dynamic runtime linking option). I
am with John on this, once you "crack the code" on how to deploy your
application with DLL libraries it is not that hard to do properly with the
dynamic runtime libraries.
The original question though was more about the clashing of the runtime library
versions which is why most of the developers that I meet we all compile our
own versions rather than relying on the vendor's version. There are just too
many variables for a vendor to try to cover to make it realistic.
Just my 2 cents.
Mike Jackson
_________________________________________________________
Mike Jackson
mike.jackson@xxxxxxxxxxxxxx<mailto:mike.jackson@xxxxxxxxxxxxxx>
BlueQuartz Software
www.bluequartz.net<http://www.bluequartz.net>
Principal Software Engineer Dayton, Ohio
On Fri, Jun 7, 2013 at 10:05 AM, Biddiscombe, John A.
<biddisco@xxxxxxx<mailto:biddisco@xxxxxxx>> wrote:
> I'd just like to second Elena's comment below. As one of the people
> responsible for the cmake implementation of hdf5, I had a really hard
> time with this static/dynamic CRT link issue.
>
> I had set up 4 nightly builds of hdf5, static and dynamic, with and
> without fortran, and unfortunately, all goes wrong when you start
> using ifort on windows because of the way the supplied fortran libs
> are linked (once you link the intel fortran libraries your link errors
> multiply and you have no control of those libraries so having an
> option to change static/dynamic is no help!)
>
> So there was not a simple combination that was easy for all setups and
> we basically opted to remove most of the options to get a combination
> that worked - It took up so much of my time that I didn't 'finish the
> job cleanly' and allow the user to decide for all cases.
>
>
>
> I would concur that
>
> 1) Adding a version stamp to the dll/lib names is desirable (and easy
> to do)
>
> 2) Adding a simple static/dynamic run time link option (and easy to do)
>
>
>
> I'm happy to test patches if people create them, but all my stuff
> works fine, so I'm not volunteering!
>
>
>
> JB
>
>
>
> [I would also personally favour dynamic linking in 99% of cases. When
> you have plugin based architectures where objects are created and
> destroyed in different modules, static linking is a no go. I do not
> suffer from DLL hell and actually find it much much much easier to
> distribute binaries to people on windows than linux]
>
>
>
>
>
> --
>
> John Biddiscombe, email:biddisco @.at.@ cscs.ch
>
> http://www.cscs.ch/
>
> CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
>
> Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Hdf-forum [mailto:hdf-forum-bounces@xxxxxxxxxxxxxxxxxx] On
> Behalf Of Elena Pourmal
> Sent: 06 June 2013 17:01
> To: HDF Users Discussion List
> Cc: help@xxxxxxxxxxxx<mailto:help@xxxxxxxxxxxx>;
> netcdfgroup@xxxxxxxxxxxxxxxx<mailto:netcdfgroup@xxxxxxxxxxxxxxxx>
>
>
> Subject: Re: [Hdf-forum] Make the Cmake Windows build static please !
>
>
>
> 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<http://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<mailto:byrn@xxxxxxxxxxxx>>
>
> To: <hdf-forum@xxxxxxxxxxxxxxxxxx<mailto: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<mailto:mike.jackson@xxxxxxxxxxxxxx>
>>> www.bluequartz.net<http://www.bluequartz.net>
>>>
>>> On Jun 5, 2013, at 8:24 AM, Pedro Vicente
>>> <pvicente@xxxxxxx<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Hdf-forum@xxxxxxxxxxxxxxxxxx>
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
