Problems compiling NetCDF on OSX with PGI 12.10

Hi, I’m having problems compiling NetCDF-Fortran 4.2 on Mac OSX (10.6.8) using PGI compilers (12.10-0). The C package for NetCDF 4.2.1.1 seems to build fine. The configure script for the Fortran package runs okay, but I get the following error when I run make check:

Making check in f90
make check-am
make[2]: Nothing to be done for `check-am’.
Making check in fortran
make check-am
Making check in nf_test
make nf_test tst_f77_v2 ftst_vars ftst_vars2 ftst_vars3 ftst_vars4 ftst_vars5 ftst_vars6 ftst_types ftst_types2 ftst_types3 ftst_groups f90tst_vars tst_types tst_types2 f90tst_vars_vlen tst_f90_nc4 f90tst_grps f90tst_fill f90tst_fill2 f90tst_vars3 f90tst_vars4 f90tst_vars2 ftst_v2 ftest tst_f90
source=‘fortlib.c’ object=‘fortlib.o’ libtool=no
DEPDIR=.deps depmode=none /bin/sh …/depcomp
pgcc -DHAVE_CONFIG_H -I. -I… -I…/fortran -DpgiFortran -I/usr/local/netcdf/4.2.1.1-pgi/include -I/usr/local/include -Msignextend -c -o fortlib.o fortlib.c
/bin/sh …/libtool --tag=F77 --mode=link pgf77 -I…/fortran -I…/f90 -w -L/usr/local/netcdf/4.2.1.1-pgi/lib -L/usr/local/lib -o nf_test test_get.o test_put.o nf_error.o nf_test.o test_read.o test_write.o util.o fortlib.o …/fortran/libnetcdff.la -lnetcdf
libtool: link: pgf77 -I…/fortran -I…/f90 -w -o nf_test test_get.o test_put.o nf_error.o nf_test.o test_read.o test_write.o util.o fortlib.o -L/usr/local/netcdf/4.2.1.1-pgi/lib -L/usr/local/lib …/fortran/.libs/libnetcdff.a -L/usr/local/netcdf/4.2.1.1-gnu/lib /usr/local/netcdf/4.2.1.1-gnu/lib/libnetcdf.dylib /usr/local/lib/libhdf5_hl.dylib /usr/local/lib/libhdf5.dylib -lm -lz
ld: duplicate symbol _main in nf_test.o and /opt/pgi/osx86-64/12.10/lib/pgfmain.o
make[2]: *** [nf_test] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1

For what it’s worth I get the same “ld: duplicate symbol _main in nf_test.o and /opt/pgi/osx86-64/12.10/lib/pgfmain.o” error when I try to build NetCDF 3.6.3 with my PGI compilers, so my guess is there’s some incompatibility between PGI 12.10 and NetCDF. I’ve already tried implementing the suggestions for building NetCDF 4.1.1 with PGI (http://www.pgroup.com/resources/netcdf/netcdf411_pgi2011.htm), but that didn’t solve my problems.

Does anyone out there have any insight that might help me solve my compilation problem? The NetCDF support list hasn’t seen this error before either, because they haven’t tested PGI compilers on OSX. Thanks in advance.

Jared

Hi Jared,

The error “ld: duplicate symbol _main” typically occurs when the program’s main program is written in C/C++ but you’re using the Fortran driver to link. The solution here is to add the flag “-Mnomain” so the the Fortran main object is not added to the link.

Hope this helps,
Mat

Hi Mat,

Thanks for the reply. Unfortunately, adding the -Mnomain flag to the Fortran compiler (“pgf90 -Mnomain”) actually caused the netcdf-fortran configure script to break:

checking for C-equivalent to Fortran routine “SUB”… sub_
checking for Fortran “byte”… yes
checking for Fortran “integer*2”… yes
checking if Fortran “byte” is C “signed char”… configure: error: Could not link conftestf.o and conftest.o

It took me awhile to figure it out, but I realized that there was one step from the NetCDF build instructions for 4.2 and later (http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-fortran-install.html) that I had inadvertently failed to do:

  1. If the netCDF C library was installed as a shared library in a location that is not searched by default, you will need to set the LD_LIBRARY_PATH environment variable (or DYLD_LIBRARY_PATH on OSX) to specify that directory before running the configure script, for example:
    export LD_LIBRARY_PATH={DIR1}/lib:$LD_LIBRARY_PATH

For me, I didn’t previously have anything set for DYLD_LIBRARY_PATH (because, oddly, if I have DYLD_LIBRARY_PATH but not LD_LIBRARY_PATH set in my environment, then Matlab for some reason won’t work, but that’s a separate issue…). But once I ditched the -Mnomain flag and set DYLD_LIBRARY_PATH, netcdf-fortran built perfectly. So if anyone else out there has a similar problem, hopefully this will get them unstuck.

Jared