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

[netCDF #NZP-417153]: compiling netcdf on windows



Hi Kavitha,

> I am trying to compile netCDF version 4.0.1 on PGI compiler on Windows
> Server 2008.

There's some information from the Portland Group on compiling netCDF-4
for Windows here:

  http://www.pgroup.com/resources/tips.htm#NETCDF

that might be useful, though we haven't tested their recommendations.

> NetCDF builds with option for shared libraries ./configure --enable-shared.

From the fact that you're using the configure script, can I assume
you're building under cygwin?

> However when I tried compiling wrf with this netCDF (which was built with
> ./configure --enable-shared option), wrf failed with the error, that looked
> like (this is only a part of the error):
> 
> libwrfio_nf.a(wrf_io.o) : error LNK2019: unresolved external symbol
> nf_inq_dimname_ referenced in function ext_ncd_read_field_
> libwrfio_nf.a(wrf_io.o) : error LNK2019: unresolved external symbol
> nf_inq_vartype_ referenced in function ext_ncd_get_var_info_
> libwrfio_nf.a(wrf_io.o) : error LNK2019: unresolved external symbol
> nf_inq_vardimid_ referenced in function ext_ncd_get_var_info_
> wrf.exe : fatal error LNK1120: 34 unresolved externals

If you were making shared libraries, the Fortran library will be
separate from the C library, and you need to link both.  So without
shared libraries you can usually use

  -LSomeLibraryDirectory -lnetcdf

but with shared libraries, you need to link to both libraries

  -LSomeLibraryDirectory -lnetcdf -lnetcdff

The Fortran library is implemented as C functions that call the
underlying C library.  The problem you're seeing could also be a
symptom of using the wrong naming conventions for C functions called
from Fortran, such as adding a single underscore.
 
> On doing some research, it seemed like, the netCDF with shared libarary
> option ( http://mailman.ucar.edu/pipermail/wrf-users/2008/000768.html
> -refer point 2 ) was the problem.
> 
> However, on configuring netCDF without shared libraries (using just
> ./configure), it resulted in failure during make of netCDF (libtool: link:
> warning: undefined symbols not allowed in i686-pc-cygwin shared libraries )

The fact that it's referring to shared libraries in the warning may also
mean it's searching in an installed shared library before trying to
link from the static library you just built.  If you really want to
link from a static library, you may have to remove (or rename) the
shared library first.

> I tried to use LDFLAGS =-no-undefined (
> http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg05086.html )
> to solve the above issue, but this fails at ./configure stage of netCDF
> itself, with the error below.

If you follow all the links in that support thread by clicking in the
"Next by thread:" line, you'll see that that solution was not what
ultimately solved that problem, but instead restoring the default
cygwin profile, which had been modified incorrectly.

> configure: finding C compiler
> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> 
> I am not sure, as to why the above errors are occuring. Any help in
> compiling netCDF is appreciated.

If you still get this error and want to proceed down this trail,
you'll need to look at the error message near the end of "config.log"
to see why the C compiler can't create executables.  It may be a
32-bit/64-bit issue.

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: NZP-417153
Department: Support netCDF
Priority: Normal
Status: Closed