[PATCH 2/N] LIBTOOLFLAGS, and *_LINK fixes for Automake 1.11
Ralf Wildenhues
Ralf.Wildenhues@gmx.de
Thu Sep 3 20:01:00 GMT 2009
[ Dave, Steve, could you please check whether the patch fixes things for
you? Thanks. ]
* Dave Korn wrote on Fri, Aug 28, 2009 at 03:55:29PM CEST:
> Ralf Wildenhues wrote:
> >> - LIBTOOLFLAGS, and *_LINK fixes for Automake 1.11 (GCC only)
> >
> > Automake handling of per-target LDFLAGS rules changed which means
> > that if you override *_LINK manually, you have to ensure that they
> > are used, too.
Unfortunately, (out of necessity) it changed much more than I figured it
did, and the NEWS entry that I quoted described, and the Automake manual
that document *LINK variables don't reflect reality fully any more
either. We need to address this upstream.
Anyway, the gist is the following:
As soon as <target>_LDFLAGS or <target>_LIBTOOLFLAGS are used now,
automake will generate a <target>_LINK variable which is used to link.
This <target>_LINK variable will however not reference $(LINK) or
$(CXXLINK) any more.
So in some cases our overriding of LINK, CXXLINK was not sufficient.
FWIW, automake does this so that AM_LDFLAGS and AM_LIBTOOLFLAGS are not
reference in the final link command line any more, so that per-target
link flags replace them, instead of just being listed afterwards.
(That's the above "out of necessity" bit.)
Now, this situation is ugly precisely because it is very unintuitive
that you'd have to override each <target>_LINK variable like that, and
I fear that, as new libraries and programs are generated in the GCC
tree, developers adding <target>_LDFLAGS will not think of adding
<target>_LINK at the same time. :-/
> Is it possible that this patch is related to a problem I'm experiencing on
> HEAD (r151124) where LTLDFLAGS in libstdc++-v3/src appears no longer to be
> used in the final link of libstdc++.la?
> It used to be that LTLDFLAGS was included in CXXLINK, which was used in the
> rule for linking libstdc++.la, but now that rule uses libstdc___la_LINK
> instead. Is it perhaps the case that both LTLDFLAGS and CXXLINK are now
> obsolete in the v3 makefiles and don't need to be defined at all?
Please try the patch below. It should fix all instances that I
introduced in r151013.
Note that I allowed myself some simplification here in that I added the
per-target link flags at the end of the command line. That means,
unlike with automake-1.11-generated lines, $(AM_LDFLAGS) still shows up,
also the $(LDFLAGS) don't come last. That shouldn't be a problem in
GCC; on the contrary, in libgomp at least it seems AM_LDFLAGS was
intended to appear in the link.
I guess I'll take the boehm-gc bit upstream; but since it addresses
a regression induced by the Automake upgrade, I think it should be
applicable in GCC even now.
Tested with a bootstrap; that's not a very effective test for this
particular bug, so I'd appreciate feedback from Dave and Steve. Thanks.
OK to apply?
This is the last autotools update-induced regression I am aware of in
the GCC tree (so please report issues if you see any other).
Thanks,
Ralf
Override all per-target *_LINK variables correctly.
boehm-gc/ChangeLog:
2009-09-03 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
* Makefile.am (libgcjgc_la_LINK, gctest_LINK): New.
(gctest_LDADD): Depend on libgcjgc.la instead of ./libgcjgc.la,
so that library dependency resolution works with portable make.
* Makefile.in: Regenerate.
libgfortran/ChangeLog:
2009-09-03 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
* Makefile.am (libgfortranbegin_la_LINK): New.
* Makefile.in: Regenerate.
libgomp/ChangeLog:
2009-09-03 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
* Makefile.am (libgomp_la_LINK): New.
* Makefile.in: Regenerate.
libjava/ChangeLog:
2009-09-03 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
* Makefile.am (libgij_la_LINK, libjvm_la_LINK): New.
* Makefile.in: Regenerate.
libstdc++-v3/ChangeLog:
2009-09-03 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
* src/Makefile.am (libstdc___la_LINK): New.
* src/Makefile.in: Regenerate.
diff --git a/boehm-gc/Makefile.am b/boehm-gc/Makefile.am
index 8438911..b074ac6 100644
--- a/boehm-gc/Makefile.am
+++ b/boehm-gc/Makefile.am
@@ -40,6 +40,7 @@ extra_ldflags_libgc = @extra_ldflags_libgc@
libgcjgc_la_LIBADD = @addobjs@ $(THREADLIBS) $(UNWINDLIBS)
libgcjgc_la_DEPENDENCIES = @addobjs@
libgcjgc_la_LDFLAGS = $(extra_ldflags_libgc) -version-info 1:2:0 -rpath $(toolexeclibdir)
+libgcjgc_la_LINK = $(LINK) $(libgcjgc_la_LDFLAGS)
libgcjgc_convenience_la_LIBADD = @addobjs@
libgcjgc_convenience_la_DEPENDENCIES = @addobjs@
@@ -49,8 +50,9 @@ AM_CFLAGS = @GC_CFLAGS@
check_PROGRAMS = gctest
gctest_SOURCES = tests/test.c
-gctest_LDADD = ./libgcjgc.la $(THREADLIBS) $(UNWINDLIBS) $(EXTRA_TEST_LIBS)
+gctest_LDADD = libgcjgc.la $(THREADLIBS) $(UNWINDLIBS) $(EXTRA_TEST_LIBS)
gctest_LDFLAGS = -shared-libgcc
+gctest_LINK = $(LINK) $(gctest_LDFLAGS)
TESTS_ENVIRONMENT = LD_LIBRARY_PATH=../../$(MULTIBUILDTOP)gcc
TESTS = gctest
diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
index 0860955..c2fd941 100644
--- a/libgfortran/Makefile.am
+++ b/libgfortran/Makefile.am
@@ -24,6 +24,7 @@ myexeclib_LTLIBRARIES = libgfortranbegin.la
myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
libgfortranbegin_la_SOURCES = fmain.c
libgfortranbegin_la_LDFLAGS = -static
+libgfortranbegin_la_LINK = $(LINK) $(libgfortranbegin_la_LDFLAGS)
## io.h conflicts with a system header on some platforms, so
## use -iquote
diff --git a/libgomp/Makefile.am b/libgomp/Makefile.am
index 5bc0732..3786bee 100644
--- a/libgomp/Makefile.am
+++ b/libgomp/Makefile.am
@@ -29,6 +29,7 @@ endif
libgomp_version_info = -version-info $(libtool_VERSION)
libgomp_la_LDFLAGS = $(libgomp_version_info) $(libgomp_version_script) \
-no-undefined -bindir "$(bindir)"
+libgomp_la_LINK = $(LINK) $(libgomp_la_LDFLAGS)
libgomp_la_SOURCES = alloc.c barrier.c critical.c env.c error.c iter.c \
iter_ull.c loop.c loop_ull.c ordered.c parallel.c sections.c single.c \
diff --git a/libjava/Makefile.am b/libjava/Makefile.am
index 13b25ac..7b6750c 100644
--- a/libjava/Makefile.am
+++ b/libjava/Makefile.am
@@ -223,6 +223,7 @@ libgij_la_LIBADD = -L$(here)/.libs libgcj.la
## The mysterious backslash in the grep pattern is consumed by make.
libgij_la_LDFLAGS = -rpath $(toolexeclibdir) \
-version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LIBGCJ_LD_SYMBOLIC)
+libgij_la_LINK = $(CXXLINK) $(libgij_la_LDFLAGS)
if INTERPRETER
libgcj_interpret_source_files = jvmti.cc interpret.cc
@@ -326,6 +327,7 @@ libjvm_la_DEPENDENCIES = libgcj.la libgcj.spec
## See jv_convert_LDADD.
libjvm_la_LIBADD = -L$(here)/.libs libgcj.la
libjvm_la_LDFLAGS = -avoid-version $(LIBGCJ_LD_SYMBOLIC)
+libjvm_la_LINK = $(CXXLINK) $(libjvm_la_LDFLAGS)
## The .db file. This rule is only used for native builds, so it is
## safe to invoke gcj-dbtool.
diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index 54d5218..9513bd5 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -209,6 +209,8 @@ libstdc___la_DEPENDENCIES = \
libstdc___la_LDFLAGS = \
-version-info $(libtool_VERSION) ${version_arg} -lm
+libstdc___la_LINK = $(CXXLINK) $(libstdc___la_LDFLAGS)
+
# Use special rules for the deprecated source files so that they find
# deprecated include files.
GLIBCXX_INCLUDE_DIR=$(glibcxx_builddir)/include
More information about the Gcc-patches
mailing list