diff mbox

Fix linking with -findirect-dispatch

Message ID mvmtxn6sbc5.fsf@hawking.suse.de
State New
Headers show

Commit Message

Andreas Schwab April 16, 2013, 4:13 p.m. UTC 
Jakub Jelinek <jakub@redhat.com> writes:

> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,

I'm pretty sure it never worked as intented.

Andreas.

	* Makefile.am (toolexeclib_LTLIBRARIES) [USE_LIBGCJ_BC]: Use
	install/libgcj_bc.la instead of libgcj_bc.la.
	(noinst_LTLIBRARIES) [USE_LIBGCJ_BC]: Define.
	(install_libgcj_bc_la_SOURCES): Define.
	(install/libgcj_bc.la): New rule.
	* Makefile.in: Rebuild.
---
 libjava/Makefile.am |  9 +++++-
 libjava/Makefile.in | 92 +++++++++++++++++++++++++++++++++++------------------
 2 files changed, 69 insertions(+), 32 deletions(-)

Comments

Jakub Jelinek April 16, 2013, 4:19 p.m. UTC | #1 
On Tue, Apr 16, 2013 at 06:13:14PM +0200, Andreas Schwab wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
> 
> I'm pretty sure it never worked as intented.

Both libraries are actually intended to be installed, not just one.
Does your patch achieve that?

	Jakub
Bryce McKinlay April 16, 2013, 4:39 p.m. UTC | #2 
On Tue, Apr 16, 2013 at 5:13 PM, Andreas Schwab <schwab@suse.de> wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
>
>> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
>
> I'm pretty sure it never worked as intented.

It certainly _did_ work as intended previously. Though I've not tested
it for a while.

Bryce
Andreas Schwab April 16, 2013, 5:22 p.m. UTC | #3 
Jakub Jelinek <jakub@redhat.com> writes:

> Both libraries are actually intended to be installed, not just one.

No, the other library is never installed, but generated on the fly.  See
<mvm8v4iu5q2.fsf@hawking.suse.de>.

Andreas.
Andreas Schwab April 17, 2013, 1:17 p.m. UTC | #4 
Bryce McKinlay <bmckinlay@gmail.com> writes:

> It certainly _did_ work as intended previously.

Only by chance, when libtool has to relink the library during install.

Andreas.
Andreas Schwab June 3, 2013, 10:55 a.m. UTC | #5 
Jakub Jelinek <jakub@redhat.com> writes:

> Both libraries are actually intended to be installed, not just one.
> Does your patch achieve that?

The patch makes sure that the standalone libgcj_bc library is correctly
built, instead of trying to install the dummy libgcj_bc library that
should only be used for testing.  Other than that nothing is changed.

Andreas.
diff mbox

Patch

diff --git a/libjava/Makefile.am b/libjava/Makefile.am
index a4941a9..208e632 100644
--- a/libjava/Makefile.am
+++ b/libjava/Makefile.am
@@ -212,7 +212,8 @@  LIBJAVA_CORE_EXTRA =
 endif
 
 if USE_LIBGCJ_BC
-toolexeclib_LTLIBRARIES += libgcj_bc.la
+toolexeclib_LTLIBRARIES += install/libgcj_bc.la
+noinst_LTLIBRARIES = libgcj_bc.la
 endif
 
 if XLIB_AWT
@@ -606,6 +607,7 @@  lib_gnu_awt_xlib_la_LINK = $(LIBLINK) $(lib_gnu_awt_xlib_la_LDFLAGS) \
 ## This lets us have one soname in BC objects and another in C++ ABI objects.
 ## This library is not linked against libgcj.
 libgcj_bc_la_SOURCES = libgcj_bc.c
+install_libgcj_bc_la_SOURCES = $(libgcj_bc_la_SOURCES)
 libgcj_bc_la_LDFLAGS = -rpath $(toolexeclibdir) -no-static -version-info 1:0:0 \
 	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS) $(LIBJAVA_LDFLAGS_NOUNDEF)
 libgcj_bc_la_DEPENDENCIES = libgcj.la $(libgcj_bc_la_version_dep)
@@ -628,6 +630,11 @@  libgcj_bc.la: $(libgcj_bc_la_OBJECTS) $(libgcj_bc_la_DEPENDENCIES)
 	rm .libs/libgcj_bc.so.1; \
 	$(LN_S) libgcj_bc.so.1.0.0 .libs/libgcj_bc.so.1
 
+## This rule creates the libgcj_bc library that is actually installed.
+install/libgcj_bc.la: $(libgcj_bc_la_OBJECTS) $(libgcj_bc_la_DEPENDENCIES) install/$(am__dirstamp)
+	$(libgcj_bc_la_LINK) $(am_libgcj_bc_la_rpath) $(libgcj_bc_la_LDFLAGS) \
+	$(libgcj_bc_la_OBJECTS) $(libgcj_bc_la_LIBADD) $(LIBS)
+
 ## Note that property_files is defined in sources.am.
 propertyo_files = $(patsubst classpath/resource/%,%,$(addsuffix .lo,$(property_files)))