Re: [PATCH] link libgcj directly to libiconv to resolve symbols
Andrew Haley <[email protected]>
| Newsgroups | gmane.comp.gcc.java.patches |
|---|---|
| Message-ID | <[email protected]> |
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.