netcdf-fortran @4.2_11 dyld failure

[jsalort (Julien Salort)]

A simple f90 file calling nf90_create results in the following error:

dyld: lazy symbol binding failed: Symbol not found: _nf_create_
  Referenced from: /opt/local/lib/libnetcdff.5.dylib
  Expected in: flat namespace

dyld: Symbol not found: _nf_create_
  Referenced from: /opt/local/lib/libnetcdff.5.dylib
  Expected in: flat namespace


Program received signal SIGTRAP: Trace/breakpoint trap.

Backtrace for this error:
#0  0x10e40de7d
#1  0x10e40e38b
#2  0x7fff85ab0909
Trace/BPT trap: 5

The file was compiled with the command:

`nc-config --fc` `nc-config --fflags` -o essai essai.f90 `nc-config --flibs`

The result of nc-config appears to be ok:

$ nc-config --fc
/opt/local/bin/gfortran-mp-4.8
$ nc-config --fflags
-pipe -Os -I/opt/local/include
$ nc-config --flibs
-L/opt/local/lib -lnetcdff -L/opt/local/lib -Wl,-headerpad_max_install_names -lnetcdf -lnetcdf

I have tried several gcc variants (gcc44, gcc46 and gcc48) but I get the same result each time on Mountain Lion with MacPorts 2.2.1. The same versions on Mavericks appears to work. Enclosed is an example simple source file grabbed from netcdf website, which reproduces the problem.

[jsalort (Julien Salort)]

Example source file

[jsalort (Julien Salort)]

The same versions on Mavericks appears to work.

Actually, there is the same problem on Mavericks after all. I thought it worked because I had netcdf-fortran @4.2_10. After updating to @4.2_11, I get the same problem on both Mavericks and Mountain Lion.

[Dave-Allured (Dave Allured)]

Same bug here.
Version netcdf-fortran @4.2_11.
Variant gcc48, I THINK.
Mac OS 10.8.5.
My local application compiler: MacPorts gcc48 4.8.2_0

Following are error messages when calling the F90 version of a simple inquiry function, nf90_inq_libvers. It is ironic that the F90 version of the function can not access the F77 version which is supposed to be in the same library! FYI, that is how this package works, most of the Fortran 90 functions are just wrappers around the F77 versions:

dyld: lazy symbol binding failed: Symbol not found: _nf_inq_libvers_
  Referenced from: /opt/local/lib/libnetcdff.5.dylib
  Expected in: flat namespace

dyld: Symbol not found: _nf_inq_libvers_
  Referenced from: /opt/local/lib/libnetcdff.5.dylib
  Expected in: flat namespace

This looks like an underscore problem! From the message above, a single trailing underscore is wanted. But the defined symbol has a double trailing underscore in the Mac Ports version:

mac56:~/pm25/prog 23> nm /opt/local/lib/libnetcdff.5.dylib | grep -i inq_libvers
00000000000481c2 T ___netcdf_MOD_nf90_inq_libvers
                 U _nc_inq_libvers
                 U _nf_inq_libvers_
00000000000051ce T _nf_inq_libvers__

When we built the same version from the original Unidata distribution, the defined symbol has only one trailing underscore, and the whole package works fine:

mac56:~/pm25/prog 28> nm /usr/local/lib/libnetcdff.5.dylib | grep -i inq_libvers
0000000000073db4 T ___netcdf_MOD_nf90_inq_libvers
                 U _nc_inq_libvers
000000000000711b T _nf_inq_libvers_

Thanks for looking into this.

--Dave

[Dave-Allured (Dave Allured)]

Cc Me!

[platipodium (Carsten Lemmen)]

Replying to lists@…:

I thought it worked because I had netcdf-fortran @4.2_10. After updating to @4.2_11, I get the same problem on both Mavericks and Mountain Lion.

So my understanding is to downgrade to @4.2_10 as a workaround for now?

[platipodium (Carsten Lemmen)]

Cc Me!

[jsalort (Julien Salort)]

Replying to carsten@…:

So my understanding is to downgrade to @4.2_10 as a workaround for now?

Yes, absolutely.

[platipodium (Carsten Lemmen)]

Replying to lists@…:

Replying to carsten@…:

So my understanding is to downgrade to @4.2_10 as a workaround for now?

Yes, absolutely.

Does not work for me (1) Downgrading via instructions on ​https://trac.macports.org/wiki/howto/InstallingOlderPort break mpich (2) simply issuing

sudo sed -i '/revision/s/11/10/' /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/science/netcdf-fortran/Portfile

and reinstalling the netcdf-fortran port does downgrade, but does not solve the linker problem

[platipodium (Carsten Lemmen)]

Replying to carsten@… and to dave.allured@…

Downgrading now gives the same problems as the current version. It all boils down to underscores

 nm /opt/local/lib/libnetcdff.* | grep _nf__create_
                 U _nf__create_
0000000000004524 T _nf__create__
                 U _nf__create_mp_
00000000000048ae T _nf__create_mp__

Reproduced with _09, _10, and _11 revisions

[jsalort (Julien Salort)]

Replying to carsten@…:

Does not work for me (1) Downgrading via instructions on ​https://trac.macports.org/wiki/howto/InstallingOlderPort break mpich

And you are absolutely sure that you properly *activated* the older port ? (sorry if the question sounds stupid)

[platipodium (Carsten Lemmen)]

Replying to lists@…:

Replying to carsten@…:

Does not work for me (1) Downgrading via instructions on ​https://trac.macports.org/wiki/howto/InstallingOlderPort break mpich

And you are absolutely sure that you properly *activated* the older port ? (sorry if the question sounds stupid)

Not stupid at all. Yes, I checked, I had the underscore mismatch with both _10 and _09 versions. So my guess is, this is related to the compiler options. I managed to install _11 by manually manipulating the configure script to include the -fno-second-underscore option.

[Dave-Allured (Dave Allured)]

Revision _08 works correctly, so the workaround is to install _08. Use the procedure in reply #10 above, worked easily for me. Note, the last changeset in _08 is @111272, this is the port file I grabbed, along with a single patch file in the subdirectory.

Caution, _08 is only compiled against gfortran 4.7, so 4.8 users would need to back their compiler down to gfortran 4.7. Not a problem for me because gfortran 4.7 was left in our system under an alternate name.

So it appears the underscore problem came somewhere within rev _09. Note, there are three different changesets under rev _09:

@114328 use eq and ne instead of == and != when comparing ${os.arch},

@112961 netcdf-fortran: Fortran variants a la PortfileRecipes#fortran

@111422 netcdf-fortran: added patch to fix a bug in configure that incorrectly

Any could be the culprit, but 112961 contains major changes.

[Dave-Allured (Dave Allured)]

Replying to carsten@…:

Not stupid at all. Yes, I checked, I had the underscore mismatch with both _10 and _09 versions. So my guess is, this is related to the compiler options. I managed to install _11 by manually manipulating the configure script to include the -fno-second-underscore option.

Normally, -fno-second-underscore should never be needed with recent gfortran versions on Mac OS. This is a symptom of a deeper problem. I second your suspicion of the other compiler options. This is about as far as I can go with this for now.

[gnurser (George Nurser)]

I've had the same prolblem. rolling back to 4.2_9 did work for me, however.

[Dave-Allured (Dave Allured)]

Replying to gnurser@…:

I've had the same prolblem. rolling back to 4.2_9 did work for me, however.

Good to get another report about 4.2_9. I could easily be mistaken in what I said before, about the problem being in 4.2_9. I did not personally test any of these interim versions, other than 4.2_8. I was just going on what others reported here.

[platipodium (Carsten Lemmen)]

I found a workaround by prepending LDFLAGS="-Wl,-flat_namespace" FFLAGS="-fno-second-underscore" before configure. Steps to reproduce:

# port install netcdf-fortran +mpich+gcc48
--->  Activating netcdf-fortran @4.2_11+gcc48+mpich
# nm /opt/local/lib/libnetcdff.dylib | grep nf_create
                U _nf_create_
000000000000446b T _nf_create__
# cd /opt/local/var/macports/build/_Users_lemmen_devel_macports_netcdf-fortran/netcdf-fortran/work/netcdf-fortran-4.2
# make distclean ; LDFLAGS="-Wl,-flat_namespace" FFLAGS="-fno-second-underscore" ./configure --prefix=/opt/local  && make install
# nm /opt/local/lib/libnetcdff.dylib | grep nf_create
00000000000018e0 T _nf_create_

Tested and working on Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64

[tenomoto (Takeshi Enomoto)]

Committed the fix in r117882. It seems that a preprocessor flag DpgiFortran was removed when PortGroup mpi was introduced. I was able to run the test program, essai. I'm sorry I have been unable to work on this for a long time.

[Dave-Allured (Dave Allured)]

Replying to takeshi@…:

Committed the fix in r117882. It seems that a preprocessor flag DpgiFortran was removed when PortGroup mpi was introduced. I was able to run the test program, essai. I'm sorry I have been unable to work on this for a long time.

I can confirm that netcdf-fortran @4.2_12 is now working fine in user land. gfortran 4.8.2 (Mac Ports). Thank you Takeshi.