dpathmgr.c: error: ‘path’ undeclared when cross-compiling netCDF 4.8.0

[Alexander-Barth]

I am trying to update the netCDF Julia package to the current version.

• the version of the software with which you are encountering an issue
  NetCDF 4.8.0

• environmental information (i.e. Operating System, compiler info, java version, python version, etc.)
  Cross-compilation from Linux to Windows (x86_64-w64-mingw32) in Julia's build tree Yggdrasil.

• a description of the issue with the steps needed to reproduce it

NetCDF is cross-compiled using the following steps (line 26-46)
https://github.com/JuliaPackaging/Yggdrasil/blob/7a37fabb2eb7c680766aea06af77a055183c92f1/N/NetCDF/common.jl#L26

In addition, we used the option CPPFLAGS=-DH5_USE_110_API.
(#1978 (comment) )

Compiliation succeeds on Linux and Mac OS, but fails on Windows with the error:

2021-05-17T15:55:38.3906619Z [15:55:38] dpathmgr.c: In function ‘NCclosedir’:
2021-05-17T15:55:38.3907622Z [15:55:38] (first use in this function)
2021-05-17T15:55:38.3908452Z [15:55:38]      char* cvtname = NCpathcvt(path);
2021-05-17T15:55:38.3909108Z [15:55:38]                                ^
2021-05-17T15:55:38.3909968Z [15:55:38] dpathmgr.c:359:31: note: each undeclared identifier is reported only once for each function it appears in

For reference the full log files is attached. I am not sure if this error is related to the option -DH5_USE_110_API.
Do you have any idea what could be the issue?
Thanks a lot for any insight!

44.txt

[DennisHeimbigner]

That is odd. In the tar file for 4.8.0, that whole last section with NCopendir and NCclosedir is disabled. because it is between

#if 0 ... #endif

Is that conditional being ignored for some reason? can you write a simple test program to see if windows ignores the 'if 0' construct?

[Alexander-Barth]

Indeed, this is very odd.
This simple test function can indeed be compiled with x86_64-w64-mingw32-gcc testc.c without errors:

#include <stdio.h>
int main() {
   // printf() displays the string inside quotation
   printf("Hello, World!");

#if 0
   undeclared_var = 0;
#endif /*0*/

   return 0;
}

However, when I use the -E gcc option to keep the pre-processed files:

# adapted command from libtool --debug
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I -DH5_USE_110_API -MT libdispatch_la-dpathmgr.lo -MD -MP -MF .deps/libdispatch_la-dpathmgr.Tpo -c dpathmgr.c -DDLL_EXPORT -DPIC -E > dpathmgr.out

I still see the function NCclosedir at line 88489 of dpathmgr.out.

NCclosedir(DIR* ent)
{
    int 
# 358 "dpathmgr.c" 3
       _stat64 
# 358 "dpathmgr.c"
            = 0;
    char* cvtname = NCpathcvt(path);
    if(cvtname == 
# 360 "dpathmgr.c" 3 4
                 ((void *)0)
# 360 "dpathmgr.c"
                     ) {
# 360 "dpathmgr.c" 3
                        (*_errno()) 
# 360 "dpathmgr.c"
                              = 
# 360 "dpathmgr.c" 3
                                2
# 360 "dpathmgr.c"
                                      ; return -1;}
    
# 361 "dpathmgr.c" 3
   _stat64 
# 361 "dpathmgr.c"
        = closedir(cvtname);
    free(cvtname);
    return 
# 363 "dpathmgr.c" 3
          _stat64
# 363 "dpathmgr.c"
              ;
}

[Alexander-Barth]

In fact the function NCclosedir is defined twice. The first definition at line 356 triggers the error
if WINPATH is defined.

netcdf-c/libdispatch/dpathmgr.c

Line 356 in 44d9d36

NCclosedir(DIR* ent)

netcdf-c/libdispatch/dpathmgr.c

Line 932 in 44d9d36

NCclosedir(DIR* ent)

[DennisHeimbigner]

ok, that explains it. Let me fix.

[DennisHeimbigner]

Still odd that I do not see this error when building under Visual Studio. Oh well, the code is wrong in any case. Wonder if this is a mingw issue? Oh, I know, mingw has dirent.h but visual studio does not.

[DennisHeimbigner]

See PR #2003