Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile errors with 4.4.1 and Visual Studio 11 (2012) #304

Closed
jmckenna opened this issue Aug 15, 2016 · 46 comments
Closed

Compile errors with 4.4.1 and Visual Studio 11 (2012) #304

jmckenna opened this issue Aug 15, 2016 · 46 comments

Comments

@jmckenna
Copy link

  • using cmake version 3.5.2
  • Visual Studio 11 (2012)
  • netcdf-c-4.4.1 release (no issues with 4.4.0 release)
  • compile errors:
>nmake /f Makefile

Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target dispatch
[  1%] Building C object libdispatch/CMakeFiles/dispatch.dir/dparallel.c.obj
dparallel.c
[  2%] Building C object libdispatch/CMakeFiles/dispatch.dir/dcopy.c.obj
dcopy.c
[  3%] Building C object libdispatch/CMakeFiles/dispatch.dir/dfile.c.obj
dfile.c
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\sys/stat.inl(52) : warning C4028: formal parameter 2 different from declaration
D:\build\mapserver-buildkit-2012\netcdf-c-4.4.1\libdispatch\dfile.c(185) : error C2143: syntax error : missing ';' before 'type'
D:\build\mapserver-buildkit-2012\netcdf-c-4.4.1\libdispatch\dfile.c(186) : error C2065: 'file_len' : undeclared identifier
D:\build\mapserver-buildkit-2012\netcdf-c-4.4.1\libdispatch\dfile.c(192) : error C2065: 'file_len' : undeclared identifier
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
@WardF
Copy link
Member

WardF commented Aug 16, 2016

Unfortunately, I don't have access to a Visual Studio 11 system anymore to debug this; I will see what I can sort out with Visual Studio 12 or 14, but as those versions don't report an error, it's possible I might not be able to fix this without additional information.

@emminizer
Copy link

emminizer commented Oct 17, 2016

I got this error today trying to compile. The problem is that MSVC 2012 (VC11) is not happy with the variable declaration in the middle of the function. If the declaration of file_len is moved up several lines, it fixes the compilation error.
FYI, There is a similar bug in dim.c's NC3_rename_dim() with the declaration of NC_string* old around line 470-ish.

@WardF
Copy link
Member

WardF commented Oct 17, 2016

Thank you for the concise description and fix! This sounds like something I can address "blind" (e.g. I can't test with VC11 myself). I'm teaching at the Unidata python workshop for the next two days but will address this ASAP.

@jmckenna
Copy link
Author

jmckenna commented Jan 9, 2017

Can I have an update on this? Has this fix been added into the distributed source code?

@WardF
Copy link
Member

WardF commented Jan 9, 2017

Thanks for the ping; I've addressed this now in a branch, gh304, and as soon as all the checks pass, I will merge this into master.

@jmckenna
Copy link
Author

jmckenna commented Jan 9, 2017

Thanks. I was hoping to confirm the changes in the gh304 branch for you, but in fact I get missing symbol errors from the linker, using the gh304 branch. Darn I'm sorry.

   Creating library netcdf.lib and object netcdf.exp
nc_initialize.c.obj : error LNK2019: unresolved external symbol _NC3_initialize referenced in function _nc_initialize
nc_initialize.c.obj : error LNK2019: unresolved external symbol _NC3_finalize referenced in function _nc_finalize
dfile.c.obj : error LNK2019: unresolved external symbol _NC3_dispatch_table referenced in function _NC_create
netcdf.dll : fatal error LNK1120: 3 unresolved externals

@WardF
Copy link
Member

WardF commented Jan 9, 2017

My initial fix was not thought out; I just moved stuff without looking at it, and this caused some failures. It shouldn't cause the failures you've just reported, but would you do a quick pull and try again? I've just pushed the fix for my initial change.

@jmckenna
Copy link
Author

jmckenna commented Jan 9, 2017

after a clean and then pull, I get the exact same 3 missing symbols error.

@WardF
Copy link
Member

WardF commented Jan 9, 2017

I've added code to accommodate Visual Studio 2012 in nc3dispatch.h and ncdispatch.h, to fix issues that would explain what you were seeing. Would you give it another try?

@jmckenna
Copy link
Author

jmckenna commented Jan 9, 2017

sorry to report, exact same 3 missing symbols after clean & pull.

@WardF
Copy link
Member

WardF commented Jan 9, 2017

Ok, I've gone through and looked everywhere I could think and cleaned up a few more places. Will you give it another try? Sorry for the repeated requests.

@WardF
Copy link
Member

WardF commented Jan 10, 2017

I'm going to merge my fixes and close out this issue; at this point there isn't anything else I can find to change, without further information re: a failure. Hopefully the last group of changes last night corrected this issue.

@WardF WardF closed this as completed Jan 10, 2017
@jmckenna
Copy link
Author

Clean & pulled again, with exact same 3 errors.

@jmckenna
Copy link
Author

It is of course ironic how I awaited since August for your feedback, but you could not await my update overnight :)

Anyway, I am sorry for this noise.

@jmckenna
Copy link
Author

To install this compiler locally, it is very easy (I have many versions of MSVC on the same machine). Here is the download link: https://www.microsoft.com/en-ca/download/details.aspx?id=34673

@jmckenna
Copy link
Author

Failing that, there should be a note in the documentation that Visual Studio 2012 is no longer supported. Ok, sorry for this long-open ticket. Thanks for your time and efforts. Ciao. -jeff

@DennisHeimbigner
Copy link
Collaborator

I am curious about this, so bear with me.
Since NC3_initialize, NC3_finalize, and NC3_dispatch_table are not being located,
it should be the case that the corresponding NC4 references e.g. NC4_dispatch_table
cannot be found either. Are you building with netcdf-4 enabled? Are you getting
corresponding NC4 errors?

@jmckenna
Copy link
Author

Thanks, sorry for my poor tone, and thanks for understanding.

I agree, it could be a unique setting in my cmake command. I am building with netcdf-4 disabled, here is the command:

cmake -G "NMake Makefiles" ..
-DCMAKE_INSTALL_PREFIX=D:\build\mapserver-buildkit-2012\netcdf-c-git-gh304\build\release
-DBUILD_SHARED_LIBS=ON
-DENABLE_NETCDF_4=OFF
-DENABLE_DAP=ON
-DBUILD_UTILITIES=OFF
-DENABLE_TESTS=OFF
-DUSE_HDF5=OFF
-DCMAKE_BUILD_TYPE=RELEASE
-DZLIB_INCLUDE_DIR="%ZLIBDIR%\include"
-DZLIB_INCLUDE_DIR="%ZLIBDIR%"
-DZLIB_LIBRARY="%ZLIBDIR%\contrib\vstudio\vc11\x86\ZlibDllRelease\zlibwapi.lib"
-DCURL_INCLUDE_DIR="%CURLDIR%\include" -DCURL_LIBRARY="%CURLDIR%\lib\libcurl_imp.lib"

@jmckenna
Copy link
Author

Oh, I am not receiving any other errors than the NC3 errors initially reported.

@DennisHeimbigner
Copy link
Collaborator

Ok, next, do you enough info from cmake or your build directory
to see if e.g. libsrc/nc3dispatch.o is being included in the linking process?

@DennisHeimbigner
Copy link
Collaborator

I am looking at include/ncdispatch.h and I see the following difference.
NCD_EXTERNL NC_Dispatch* NC3_dispatch_table;
vs
extern NC_Dispatch* NC3_dispatch_table;

Similarly for NC3_initialize and NC3_finalize.

Try as an experiment to make the declarations ofr NC3_... the same
as for NC4_...
If you use 'extern' then II would expect NC3_dispatch_table to be found.
If you use 'NCD_EXTERNL' then II would expect NC4_dispatch_table to start failing.

@jmckenna
Copy link
Author

I see, on lines 130-132. Will try now...

@jmckenna
Copy link
Author

Darn still the same errors (this seemed like it should work).

nc_initialize.c.obj : error LNK2019: unresolved external symbol _NC3_initialize referenced in function _nc_initialize
nc_initialize.c.obj : error LNK2019: unresolved external symbol _NC3_finalize referenced in function _nc_finalize
dfile.c.obj : error LNK2019: unresolved external symbol _NC3_dispatch_table referenced in function _NC_create
netcdf.dll : fatal error LNK1120: 3 unresolved externals

@jmckenna
Copy link
Author

There is no file named nc3dispatch.obj in the build directory either.

@WardF WardF reopened this Jan 10, 2017
@jmckenna
Copy link
Author

I notice in my 4.4.0 build directory, the file nc3dispatch.c.obj is generated (but not in the gh304 branch).

@WardF
Copy link
Member

WardF commented Jan 10, 2017

I've reopened; no worries about the tone. It wasn't closed because I hadn't heard from you, it was closed because there wasn't a 'next step' on my end. Thanks for providing the link to the VS11 install, I've reopened this while I try to debug on my end. I'm updating my Windows VM and then will install VS11 and try to recreate this.

Regarding the NCD_EXTERNL; unfortunately, @DennisHeimbigner , Visual Studio (until recently) wouldn't work with extern; you had to specify whether you were importing/exporting symbols. The symbols mentioned above weren't being set with NCD_EXTERNL, that change is part of the fix I made. It's why I'm confused why this is still occurring. I'll get VS11 installed and see if I can recreate this.

@WardF WardF self-assigned this Jan 10, 2017
@WardF WardF added this to the 4.4.2 milestone Jan 10, 2017
@DennisHeimbigner
Copy link
Collaborator

Ok, then judging from the most recent comments, I would
expect that there is some other error occurring during the compilation of
libsrc so that it is not completing, but the build continues. Hence the
missing items. So, you need to make cmake run as verbosely as possible,,
look at the compilation of libsrc and see if there is some other fatal error
occurring.

@WardF
Copy link
Member

WardF commented Jan 10, 2017 via email

@WardF
Copy link
Member

WardF commented Jan 10, 2017

Ok, I have something that works with Visual Studio 2012 now; can you confirm it works on your end? It's in the master branch.

@jmckenna
Copy link
Author

Same exact 3 errors with today's master branch.

@jmckenna
Copy link
Author

Similar as before: I notice in my 4.4.0 build directory, the file nc3dispatch.c.obj is generated (but not in the master branch).

@WardF
Copy link
Member

WardF commented Jan 11, 2017

Ok. I'm starting to wonder if this is environmental, as I can no longer recreate the issue with visual studio 12. Can you give it a try in a completely new build directory? Also, can you build the 'Experimental' target so that the results are uploaded to our web dashboard where I can investigate them? You can build this from visual studio, I'm certain, or from the command line you can run:

cmake --build . --config Release --target Experimental

(after running the initial cmake command, of course).

@jmckenna
Copy link
Author

No problem. (I delete my build directory each time, by the way). More shortly...

@jmckenna
Copy link
Author

Submit files (using http)
   Using HTTP submit method
   Drop site:http://
   Submit failed, waiting 5 seconds...
   Retry submission: Attempt 1 of 3
   Submit failed, waiting 5 seconds...
   Retry submission: Attempt 2 of 3
   Submit failed, waiting 5 seconds...
   Retry submission: Attempt 3 of 3
   Error when uploading file: D:/build/mapserver-buildkit-2012/netcdf-c-git-master/build/Testing/20170111-1755/Build.xml
   Error message was: Couldn't resolve host 'http'

@jmckenna
Copy link
Author

attached the build output: build.zip

@WardF
Copy link
Member

WardF commented Jan 11, 2017

This is very odd. The CMakeLists.txt file you're working from should set the appropriate values (NC_CTEST_SITE, NC_CTEST_DROP_SITE, NC_CTEST_DROP_LOC_PREFIX, etc) assuming that you're building with tests enabled; I see you don't actually say that that is what you're doing, so perhaps an incorrect assumption on my part. If you aren't running with tests enabled, can you re-build, with tests enabled, and then try the experimental target again?

@jmckenna
Copy link
Author

my full cmake command is above (I assumed you were using my exact command in your local tests). As noted, it includes: -DENABLE_TESTS=OFF

@jmckenna
Copy link
Author

Ok trying with -DENABLE_TESTS=ON now....

@WardF
Copy link
Member

WardF commented Jan 11, 2017 via email

@jmckenna
Copy link
Author

"Submission successful"

@WardF
Copy link
Member

WardF commented Jan 11, 2017

ah! Thank you, I think I see the error. Let me check a couple things to make sure I'm on the right track. If you're interested, you can view the results at:

Only the build failure is of interest; the tests failed as one would expect.

My suspicion is that you do not have m4 installed on your system, which explains why the generated file putget.c is not being found. You can see this detail at:

We include the generated .c files in releases, but not in the development branch. The solution may be as easy as installing m4, but I don't want to say that's what needs to be done until I've looked into it a bit more. I have m4 as a side-effect of other packages I've installed, not because I set out to install it.

@jmckenna
Copy link
Author

That dashboard is super cool! Glad it was helpful.

You're correct on m4 missing on my build system. Let me know what you recommend for my case...

@WardF
Copy link
Member

WardF commented Jan 11, 2017

Ok, I think your best bet will be to download and install the m4 utility on your system, ensuring that it is on the system path so that it can be executed by cmake. You can find the m4 website here:

@DennisHeimbigner
Copy link
Collaborator

So I can be clear, this m4 issue is when building from github, not when building
from our distributions, correct?

@WardF
Copy link
Member

WardF commented Jan 11, 2017

Correct; it gives an indication that there was a problem, but it is not obvious that the lack of m4 was the issue. We adhere to the general rule of thumb of "don't commit generated files" for the development branches, but when there is a release, I ensure that all of the generated files are included as part of the distribution. The assumption I've made is that if you are working with the development branch, you are likely a developer, and if you are a developer you will either have m4, or be up for installing it in your environment (as it is a common enough tool).

There is no such assumption for end users who are installing releases, so I make sure they have the files they need :). At least, I try to.

@jmckenna
Copy link
Author

jmckenna commented Jan 11, 2017

Bingo, works! It was indeed the missing m4.exe in my path. In my case, I already had MSYS/MinGW on the system, so all I needed to do was make sure that its bin directory was included in my PATH with

  set PATH=%PATH%;C:\MinGW\msys\1.0\bin

netcdf.dll compiles now with master and Visual Studio 2012. Thank you @WardF for all this effort! I've made notes on this requirement of m4, for when I need master or other branches again. Let me know if I can help by adding this note anywhere else, publicly, so other developers can find it.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue May 16, 2018
Upstream changes:
## 4.6.1 - March 15, 2018

* [Bug Fix] Corrected an issue which could result in a dap4 failure. See [Github #888](Unidata/netcdf-c#888) for more information.
* [Bug Fix][Enhancement] Allow `nccopy` to control output filter suppresion.  See [Github #894](Unidata/netcdf-c#894) for more information.
* [Enhancement] Reverted some new behaviors that, while in line with the netCDF specification, broke existing workflows.  See [Github #843](Unidata/netcdf-c#843) for more information.
* [Bug Fix] Improved support for CRT builds with Visual Studio, improves zlib detection in hdf5 library. See [Github #853](Unidata/netcdf-c#853) for more information.
* [Enhancement][Internal] Moved HDF4 into a distinct dispatch layer. See [Github #849](Unidata/netcdf-c#849) for more information.

## 4.6.0 - January 24, 2018
* [Enhancement] Full support for using HDF5 dynamic filters, both for reading and writing. See the file docs/filters.md.
* [Enhancement] Added an option to enable strict null-byte padding for headers; this padding was specified in the spec but was not enforced.  Enabling this option will allow you to check your files, as it will return an E_NULLPAD error.  It is possible for these files to have been written by older versions of libnetcdf.  There is no effective problem caused by this lack of null padding, so enabling these options is informational only.  The options for `configure` and `cmake` are `--enable-strict-null-byte-header-padding` and `-DENABLE_STRICT_NULL_BYTE_HEADER_PADDING`, respectively.  See [Github #657](Unidata/netcdf-c#657) for more information.
* [Enhancement] Reverted behavior/handling of out-of-range attribute values to pre-4.5.0 default. See [Github #512](Unidata/netcdf-c#512) for more information.
* [Bug] Fixed error in tst_parallel2.c. See [Github #545](Unidata/netcdf-c#545) for more information.
* [Bug] Fixed handling of corrupt files + proper offset handling for hdf5 files. See [Github #552](Unidata/netcdf-c#552) for more information.
* [Bug] Corrected a memory overflow in `tst_h_dimscales`, see [Github #511](Unidata/netcdf-c#511), [Github #505](Unidata/netcdf-c#505), [Github #363](Unidata/netcdf-c#363) and [Github #244](Unidata/netcdf-c#244) for more information.

## 4.5.0 - October 20, 2017

* Corrected an issue which could potential result in a hang while using parallel file I/O. See [Github #449](Unidata/netcdf-c#449) for more information.
* Addressed an issue with `ncdump` not properly handling dates on a 366 day calendar. See [GitHub #359](Unidata/netcdf-c#359) for more information.

### 4.5.0-rc3 - September 29, 2017

* [Update] Due to ongoing issues, native CDF5 support has been disabled by **default**.  You can use the options mentioned below (`--enable-cdf5` or `-DENABLE_CDF5=TRUE` for `configure` or `cmake`, respectively).  Just be aware that for the time being, Reading/Writing CDF5 files on 32-bit platforms may result in unexpected behavior when using extremely large variables.  For 32-bit platforms it is best to continue using `NC_FORMAT_64BIT_OFFSET`.
* [Bug] Corrected an issue where older versions of curl might fail. See [GitHub #487](Unidata/netcdf-c#487) for more information.
* [Enhancement] Added options to enable/disable `CDF5` support at configure time for autotools and cmake-based builds.  The options are `--enable/disable-cdf5` and `ENABLE_CDF5`, respectively.  See [Github #484](Unidata/netcdf-c#484) for more information.
* [Bug Fix] Corrected an issue when subsetting a netcdf3 file via `nccopy -v/-V`. See [Github #425](Unidata/netcdf-c#425) and [Github #463](Unidata/netcdf-c#463) for more information.
* [Bug Fix] Corrected `--has-dap` and `--has-dap4` output for cmake-based builds. See [GitHub #473](Unidata/netcdf-c#473) for more information.
* [Bug Fix] Corrected an issue where `NC_64BIT_DATA` files were being read incorrectly by ncdump, despite the data having been written correctly.  See [GitHub #457](Unidata/netcdf-c#457) for more information.
* [Bug Fix] Corrected a potential stack buffer overflow.  See [GitHub #450](Unidata/netcdf-c#450) for more information.

### 4.5.0-rc2 - August 7, 2017

* [Bug Fix] Addressed an issue with how cmake was implementing large file support on 32-bit systems. See [GitHub #385](Unidata/netcdf-c#385) for more information.
* [Bug Fix] Addressed an issue where ncgen would not respect keyword case. See [GitHub #310](Unidata/netcdf-c#310) for more information.

### 4.5.0-rc1 - June 5, 2017

* [Enhancement] DAP4 is now included. Since dap2 is the default for urls, dap4 must be specified by
(1) using "dap4:" as the url protocol, or
(2) appending "#protocol=dap4" to the end of the url, or
(3) appending "#dap4" to the end of the url
Note that dap4 is enabled by default but remote-testing is
disbled until the testserver situation is resolved.
* [Enhancement] The remote testing server can now be specified with the `--with-testserver` option to ./configure.
* [Enhancement] Modified netCDF4 to use ASCII for NC_CHAR.  See [Github Pull request #316](Unidata/netcdf-c#316) for more information.
* [Bug Fix] Corrected an error with how dimsizes might be read. See [Github #410](Unidata/netcdf-c#410) for more information.
* [Bug Fix] Corrected an issue where 'make check' would fail if 'make' or 'make all' had not run first.  See [Github #339](Unidata/netcdf-c#339) for more information.
* [Bug Fix] Corrected an issue on Windows with Large file tests. See [Github #385](Unidata/netcdf-c#385]) for more information.
* [Bug Fix] Corrected an issue with diskless file access, see [Pull Request #400](Unidata/netcdf-c#400) and [Pull Request #403](Unidata/netcdf-c#403) for more information.
* [Upgrade] The bash based test scripts have been upgraded to use a common test_common.sh include file that isolates build specific information.
* [Upgrade] The bash based test scripts have been upgraded to use a common test_common.sh include file that isolates build specific information.
* [Refactor] the oc2 library is no longer independent of the main netcdf-c library. For example, it now uses ncuri, nclist, and ncbytes instead of its homegrown equivalents.
* [Bug Fix] `NC_EGLOBAL` is now properly returned when attempting to set a global `_FillValue` attribute. See [GitHub #388](Unidata/netcdf-c#388) and [GitHub #389](Unidata/netcdf-c#389) for more information.
* [Bug Fix] Corrected an issue where data loss would occur when `_FillValue` was mistakenly allowed to be redefined.  See [Github #390](Unidata/netcdf-c#390), [GitHub #387](Unidata/netcdf-c#387) for more information.
* [Upgrade][Bug] Corrected an issue regarding how "orphaned" DAS attributes were handled. See [GitHub #376](Unidata/netcdf-c#376) for more information.
* [Upgrade] Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md).
* [Bug] Addressed conversion problem with Windows sscanf.  This primarily affected some OPeNDAP URLs on Windows.  See [GitHub #365](Unidata/netcdf-c#365) and [GitHub #366](Unidata/netcdf-c#366) for more information.
* [Enhancement] Added support for HDF5 collective metadata operations when available. Patch submitted by Greg Sjaardema, see [Pull request #335](Unidata/netcdf-c#335) for more information.
* [Bug] Addressed a potential type punning issue. See [GitHub #351](Unidata/netcdf-c#351) for more information.
* [Bug] Addressed an issue where netCDF wouldn't build on Windows systems using MSVC 2012. See [GitHub #304](Unidata/netcdf-c#304) for more information.
* [Bug] Fixed an issue related to potential type punning, see [GitHub #344](Unidata/netcdf-c#344) for more information.
* [Enhancement] Incorporated an enhancement provided by Greg Sjaardema, which may improve read/write times for some complex files.  Basically, linked lists were replaced in some locations where it was safe to use an array/table.  See [Pull request #328](Unidata/netcdf-c#328) for more information.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants