Re: having a lot of mingw build problems with atexit - what does it mean?

[Ralf Wildenhues]

Hello Ed,

* Ed Hartnett wrote on Fri, Dec 08, 2006 at 03:12:34AM CET:
> 
> This must have been a Nd problem. When I upgraded to gcc 3.4.2
> the whole problem went away.

Hmm, that still worries me, plus I'm not sure what Nd means;
is that similar to PEBKAC?

Anyway, here's a patch for you to cope with changes between Automake
1.9.6 and 1.10; quoting its NEWS file:

| - Per-target flags are now correctly handled in link rules.
|
|   For instance maude_CFLAGS correctly overrides AM_CFLAGS; likewise
|   for maude_LDFLAGS and AM_LDFLAGS.  Previous versions bogusly
|   preferred AM_CFLAGS over maude_CFLAGS while linking, and they
|   used both AM_LDFLAGS and maude_LDFLAGS on the same link command.
|
|   The fix for compiler flags (i.e., using maude_CFLAGS instead of
|   AM_CFLAGS) should not hurt any package since that is how _CFLAGS
|   is expected to work (and actually works during compilation).
|
|   However using maude_LDFLAGS "instead of" AM_LDFLAGS rather than
|   "in addition to" breaks backward compatibility with older versions.
|   If your package used both variables, as in
|
|     AM_LDFLAGS = common flags
|     bin_PROGRAMS = a b c
|     a_LDFLAGS = more flags
|     ...
|
|   and assumed *_LDFLAGS would sum up, you should rewrite it as
|
|     AM_LDFLAGS = common flags
|     bin_PROGRAMS = a b c
|     a_LDFLAGS = $(AM_LDFLAGS) more flags
|     ...
|
|   This new behavior of *_LDFLAGS is more coherent with other
|   per-target variables, and the way *_LDFLAGS variables were
|   considered internally.

When used with 1.9.6, they cause some harmless doubled command line
entries.

Cheers,
Ralf

--- netcdf-3.6.2-beta5/cxx/Makefile.am  2006-09-29 14:54:28.000000000 +0200
+++ netcdf-3.6.2-beta5/cxx/Makefile.am  2006-12-05 19:53:26.000000000 +0100
@@ -75,7 +75,7 @@
 # Library source.
 libnetcdf_c___la_SOURCES = netcdf.cpp ncvalues.cpp
 
-libnetcdf_c___la_LDFLAGS = -version-info 0:0:0 
+libnetcdf_c___la_LDFLAGS = $(AM_LDFLAGS) -version-info 0:0:0 
 
 test: check
 
--- netcdf-3.6.2-beta5/fortran/Makefile.am      2006-09-29 14:54:28.000000000 
+0200
+++ netcdf-3.6.2-beta5/fortran/Makefile.am      2006-12-05 19:52:00.000000000 
+0100
@@ -18,7 +18,7 @@
 # Does the user wants separate fortran libraries?
 if BUILD_SEPARATE_FORTRAN
 lib_LTLIBRARIES = libnetcdff.la
-libnetcdff_la_LDFLAGS = -version-info 0:0:0
+libnetcdff_la_LDFLAGS = $(AM_LDFLAGS) -version-info 0:0:0
 else
 noinst_LTLIBRARIES = libnetcdff.la
 endif
--- netcdf-3.6.2-beta5/libsrc/Makefile.am       2006-12-02 13:55:01.000000000 
+0100
+++ netcdf-3.6.2-beta5/libsrc/Makefile.am       2006-12-05 19:30:20.000000000 
+0100
@@ -80,7 +80,7 @@
 # their functions in the C library.
 if !BUILD_SEPARATE_FORTRAN
 
-# If F77 is built, include it's convenience library. If F90 is built,
+# If F77 is built, include its convenience library. If F90 is built,
 # it will also be part of this convenience library.
 if BUILD_F77
 libnetcdf_la_LIBADD += ../fortran/libnetcdff.la
@@ -89,7 +89,7 @@
 endif # !BUILD_SEPARATE_FORTRAN
 
 # Verson for the netcdf-3 library.
-libnetcdf_la_LDFLAGS = -version-info 0:0:0 -no-undefined
+libnetcdf_la_LDFLAGS = $(AM_LDFLAGS) -version-info 0:0:0 -no-undefined
 
 # If building the DLL on mingw, we need extra arguments to produce the
 # def file, which is needed by MS tools to create the VC++ import