This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] link libgcj directly to libiconv to resolve symbols
- From: Andrew Haley <aph at redhat dot com>
- To: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- Cc: java-patches at gcc dot gnu dot org
- Date: Fri, 05 Jul 2013 17:25:47 +0100
- Subject: Re: [PATCH] link libgcj directly to libiconv to resolve symbols
- References: <20130705161058 dot GA15079 at bromo dot med dot uc dot edu>
On 07/05/2013 05:10 PM, Jack Howarth wrote:
> 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?
No. Some systems have iconv in libc, some have it in libiconv.
Andrew.