This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

[PATCH] link libgcj directly to libiconv to resolve symbols

From: Jack Howarth <howarth at bromo dot med dot uc dot edu>
To: java at gcc dot gnu dot org
Cc: per at bothner dot com, aph at redhat dot com, tromey at redhat dot com
Date: Fri, 5 Jul 2013 09:51:22 -0400
Subject: [PATCH] link libgcj directly to libiconv to resolve symbols

   Currently the build of the libgcj shared library in libjava omits a direct linkage against the
libiconv shared library to resolve the undefined _libiconv, _libiconv_close and _libiconv_open
symbols in libgcj. My understanding of shared library best practices is that shared libraries
should always be linked directly to the those shared libraries required to resolve their undefined
symbols rather than postponing this linkage until when the shared library is used (as is currently
done in libjava/libgcj.spec.in).
   The attached patch achieves this by removing the @LIBMATHSPEC@ from *lib: in libjava/libgcj.spec.in
and moving it as $(LDLIBICONV) onto libgcj_la_LDFLAGS in libjava/Makefile.am and libjava/Makefile.in. 
Bootstrap and regression tested on x86_64-apple-darwin12 for gcc trunk and gcc-4_8-branch.
Okay for gcc trunk and gcc-4_8-branch?
         Jack

Attachment: link_libgcj_to_libiconv.diff
Description: Text document

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]