#118 Parallel-build breakage (wrong libnco linked)

[Daniel Macks]

Several Makefile recipes involve linking binaries against the libnco library that is part of this distro. Many of those specify it as foo_LDADD = libnco.la, but some have foo_LDADD=-lnco instead. The former causes linking directly to the library that was built whereas the latter searches -L paths (which can include global locations that have all sorts of other things installed). Part of the autotools magic is that the former automatically sets a foo:libnco.la dependency, whereas the latter does not. As a result, the latter has the possibility of libnco not yet being fully compiled by the time foo is linked, and -lnco resolving to a different version in the globally installed directories. Here are the places:

• configure.ac line 410 - no idea how to diagnose what this does or fix it because I am on OS X:)

• nco++/Makefile.am several places. "-L../nco" should be removed and "-lnco" replaced by "../libnco.la" everywhere.

• nco_c++/Makefile.am line 24 should change:

-tst_LDADD = -lnco_c++
+tst_LDADD = libnco_c++.la

[Daniel Macks]

Oh, and per autotools docs, -lfoo and libfoo.la flags should go in foo_LDADD not foo_LDFLAGS.

[Charlie Zender]

Thank you for reporting this Daniel. We are woefully incompetent with autoconf. It would be great if you would create a PR with all the fixes you deem necessary :)

[Charlie Zender]

I tried your suggestions. Replacing -lnco with -l../nco/libnco.la works. In fact it fixes a longstanding compiler issue with ncap2 on Cori at NERSC. However, replacing ncap2_LDFLAGS with ncap2_LDADD produces errors. I would be grateful if you could try that and offer any insight.

[Daniel Macks]

Is the current code in git (or CVS, or...) somewhere?

[Charlie Zender]

github.com/nco/nco.git

[Charlie Zender]

Daniel, we are closing this because the patch you provided (thanks for trying!) breaks our regression tests as described on the GitHub PR page.