[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #UEA-649834]: Bug report - Building on Windows

Hello Philip,

Thank you for your comprehensive report; I'm sure we can get this sorted out.  
I will preface this message with the fact that I haven't tried building netcdf 
with the latest Visual Studio yet, but since I've had two questions about it 
this morning I'm going to give it a try later today.  I will follow up later if 
doing so renders my speculation below moot.

I agree with your diagnoses that Visual Studio/CMake was not picking up the 
hdf5 dependencies, for some reason.  I have a few thoughts, which I'll outline 
below in no particular order.

1. After running cmake, there should be a file in the build directory called 
`libnetcdf.settings`; under 'Extra Libraries' does it reference libhdf5?  This 
will help determine if the issue is with cmake not properly finding libhdf5, or 
if there is a problem generated the project files.
2. I notice that the configuration being built is `MinSizeRel`; what happens if 
you try to build the simple `Release` or `Debug` configuration (note that Debug 
is very noisy and will interrupt you with warning pop-ups, if you try to run it 
in production)?  It could be an issue with how I've configured CMake to set 
library dependencies and simply did not account for MinSizeRel.  
3. How are you building netcdf?  After running your batch file, what happens if 
you run (at the top of the build directory) `cmake --build . --config Release 
--target netcdf`? Do you see the same/similar issues?
4. Thank you for the bug report re: snprintf; even if it's a cmake bug, I 
should work around it if at all possible, and will strive to do so.

As mentioned above, I will be installing the latest Visual Studio later today 
and will see what happens.  I use a script to deploy a new development 
environment; this script compiles libhdf5 + deps, libhdf4 +deps, and libcurl 
using a specified compiler.  I assume that any issues stemming from the latest 
Visual Studio will be made readily apparent.  If I discover anything, I will 
follow up directly with you; otherwise please feel free to try the things I 
mention above, and let me know if the outcome changes.

Thanks, have a great day,

-Ward


> Hi, I am trying to build the netcdf library on Windows, but I am having 
> linker issues.
> My system is running Windows 10, I am using Visual studio 2015 and I have 
> installed hdf5 using their binary Windows installer and I have downloaded the 
> Curl/libcurl binaries for windows. I am trying to build netcdf 4.3.3 and am 
> using CMake 3.3.2.
> 
> I generate VS 2015 .sln files by creating a build directory within the source 
> directory, then I add the following to a batch file in the build directory 
> and run it from VS 2015 x64 native command line
> 
> @set CFLAGS=/DUNICODE /D_UNICODE
> @set LOCAL=D:/usr/local/
> cmake .. -G "Visual Studio 14 2015 Win64" -DCMAKE_INSTALL_PREFIX="%LOCAL%" 
> -DCMAKE_LIBRARY_PATH="%LOCAL%lib" -DCURL_LIBRARY="%LOCAL%lib\libcurldll.a" 
> -DCURL_INCLUDE_DIR=%LOCAL%include
> 
> This generates my .sln, which contains a number of projects. When I try to 
> build the INSTALL project I get a number of linker errors and failed builds. 
> I think the crux of the problem is that the netcdf project, which builds 
> netcdf.dll fails with the following linker errors
> 
> 1>------ Build started: Project: netcdf, Configuration: MinSizeRel x64 ------
> 1>     Creating library 
> D:/usr/local/src/netcdf-4.3.3/build/liblib/MinSizeRel/netcdf.lib and object 
> D:/usr/local/src/netcdf-4.3.3/build/liblib/MinSizeRel/netcdf.exp
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_SCHAR_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_SCHAR_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_UCHAR_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_UCHAR_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_SHORT_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_SHORT_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_USHORT_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_USHORT_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_INT_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_INT_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_UINT_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_UINT_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_LLONG_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_LLONG_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_ULLONG_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_ULLONG_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_FLOAT_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_FLOAT_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol H5T_NATIVE_DOUBLE_g 
> referenced in function get_netcdf_type
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol H5T_NATIVE_DOUBLE_g
> 1>nc4file.obj : error LNK2019: unresolved external symbol 
> H5P_CLS_FILE_CREATE_ID_g referenced in function nc4_create_file
> 1>nc4file.obj : error LNK2019: unresolved external symbol 
> H5P_CLS_FILE_ACCESS_ID_g referenced in function nc4_create_file
> 1>nc4var.obj : error LNK2019: unresolved external symbol 
> H5P_CLS_DATASET_ACCESS_ID_g referenced in function nc4_reopen_dataset
> 1>nc4hdf.obj : error LNK2001: unresolved external symbol 
> H5P_CLS_DATASET_ACCESS_ID_g
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_IEEE_F32BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_IEEE_F32LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_IEEE_F64BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_IEEE_F64LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I8BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I8LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I16BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I16LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I32BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I32LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I64BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_I64LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U8BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U8LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U16BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U16LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U32BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U32LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U64BE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_STD_U64LE_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol H5T_C_S1_g 
> referenced in function nc4_get_hdf_typeid
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol 
> H5P_CLS_DATASET_CREATE_ID_g referenced in function var_create_dataset
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol 
> H5P_CLS_DATASET_XFER_ID_g referenced in function nc4_get_vara
> 1>nc4hdf.obj : error LNK2019: unresolved external symbol 
> H5P_CLS_GROUP_CREATE_ID_g referenced in function create_group
> 1>D:\usr\local\src\netcdf-4.3.3\build\liblib\MinSizeRel\netcdf.dll : fatal 
> error LNK1120: 37 unresolved externals
> ========== Build: 0 succeeded, 1 failed, 6 up-to-date, 0 skipped ==========
> 
> These are all functions which should be exported by the hdf5 export library. 
> When I looked at the propertied for the netcdf project it appears that the 
> hdf5 libraries are not included in the Linker->Input-> Additional 
> Dependencies, so I tried adding them manually. This field now looks like
> kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;D:\usr\local\lib\zlib.lib;D:\usr\local\lib\libcurldll.a;D:\usr\local\lib\hdf5.lib;D:\usr\local\lib\hdf5_hl.lib
> 
> Despite adding the hdf5 libraries I still see the linker errors!
> 
> I must confess that my experience building dlls is limited as I usually build 
> static libraries. The reason I am trying to build dlls is that I have 
> recently upgraded to VS 2015 and that process has been rather difficult 
> because all my static libraries have had to be rebuilt to maintain 
> compatibility – hence I am moving to dlls to avoid the same problem in the 
> future.
> 
> Any advice very welcome.
> 
> Phil
> 
> PS there also seems to be a bug related to snprintf. This function now exists 
> in stdio.h, but is not picked up by your CMake checks so gets redefined in 
> config.h. However I guess this is a CMake bug, rather than a netcdf bug.
> 
> ________________________________________
> Dr Phil Rosenberg
> Institute of Climate and Atmospheric Science
> School of Earth and Environment
> University of Leeds
> LS2 9JT
> 0113 34 34931
> 
> 


Ticket Details
===================
Ticket ID: UEA-649834
Department: Support netCDF
Priority: Normal
Status: Closed