[PATCH] link libgcj directly to libiconv to resolve symbols

[PATCH] link libgcj directly to libiconv to resolve symbols

[Jack Howarth]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

   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 #2: link_libgcj_to_libiconv.diff --]
[-- Type: text/plain, Size: 2336 bytes --]

2013-07-05  Jack Howarth  <howarth@bromo.med.uc.edu>

libjava/

        PR java/49441 
        * libgcj.spec.in (*lib:): Remove @LDLIBICONV@.
        * Makefile.am (libgcj_la_LDFLAGS): Add $(LDLIBICONV).
	* Makefile.in (libgcj_la_LDFLAGS): Regenerated.


Index: libjava/libgcj.spec.in
===================================================================
--- libjava/libgcj.spec.in	(revision 200713)
+++ libjava/libgcj.spec.in	(working copy)
@@ -7,6 +7,6 @@
 *startfile: @THREADSTARTFILESPEC@ %(startfileorig)
 
 %rename lib liborig
-*lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ @LIBMATHSPEC@ @LDLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig)
+*lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ @LIBMATHSPEC@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig)
 
 *jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ @LIBGCJ_BC_SPEC@ -fkeep-inline-functions
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 200713)
+++ libjava/Makefile.am	(working copy)
@@ -492,7 +492,7 @@ xlib_nat_files = $(xlib_nat_source_files
 libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLDFLAGS) $(extra_ldflags) $(THREADLIBS) \
 	$(LIBLTDL) $(SYS_ZLIBS) $(LIBJAVA_LDFLAGS_NOUNDEF) \
 	-version-info `grep -v '^\#' $(srcdir)/libtool-version` \
-	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS) $(LIBGCJ_LD_EXPORT_ALL)
+	$(LIBGCJ_LD_SYMBOLIC_FUNCTIONS) $(LIBGCJ_LD_EXPORT_ALL) $(LDLIBICONV)
 libgcj_la_LIBADD = \
 	classpath/native/fdlibm/libfdlibm.la \
 	java/lang/Object.lo \
Index: configure
===================================================================
--- configure	(revision 200713)
+++ configure	(working copy)
@@ -7416,6 +7416,13 @@ if test x${is_cross_compiler} = xyes ; t
   target_configargs="--with-cross-host=${host_noncanonical} ${target_configargs}"
 fi
 
+# Pass --with-sysroot on darwin without SDK in /
+case "${target}" in
+  x86_64-*-darwin1[3-9]*)
+    host_configargs="--with-sysroot=\"`xcrun --show-sdk-path`\"  ${host_configargs}"
+    ;;
+esac
+
 # Default to --enable-multilib.
 if test x${enable_multilib} = x ; then
   target_configargs="--enable-multilib ${target_configargs}"

Re: [PATCH] link libgcj directly to libiconv to resolve symbols

[Andrew Haley]

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.

Re: [PATCH] link libgcj directly to libiconv to resolve symbols

[Jack Howarth]

On Fri, Jul 05, 2013 at 05:25:47PM +0100, Andrew Haley wrote:
> 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.

   I assume you are doing this to create binary tarball distributions which can be deployed on
various linux distros, correct? Isn't this rather dangerous as you are compiling libgcj against
the headers of some unknown libiconv release and then having it linked against a completely
different one when deployed in the field. Doesn't this require a lot of assumptions about the
data structures on libiconv calls not changing between the various releases? It would seem to
be safier if you just added an option to statically link libiconv.a into libgcj if such a
portable tarball release was required.
                 Jack

> 
> Andrew.
> 

Re: [PATCH] link libgcj directly to libiconv to resolve symbols

[Andrew Haley]

On 07/06/2013 04:58 AM, Jack Howarth wrote:
> On Fri, Jul 05, 2013 at 05:25:47PM +0100, Andrew Haley wrote:
>> 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.
> 
>    I assume you are doing this to create binary tarball
> distributions which can be deployed on various linux distros,
> correct? Isn't this rather dangerous as you are compiling libgcj
> against the headers of some unknown libiconv release and then having
> it linked against a completely different one when deployed in the
> field.

It's never broken anything before.  Why would it do so now?

> Doesn't this require a lot of assumptions about the data structures
> on libiconv calls not changing between the various releases? It
> would seem to be safier if you just added an option to statically
> link libiconv.a into libgcj if such a portable tarball release was
> required.

It'd help a lot if you explained what problem you're trying to solve.
"shared library best practices" doesn't quite do it.

Andrew.

Re: [PATCH] link libgcj directly to libiconv to resolve symbols

[Jack Howarth]

On Sat, Jul 06, 2013 at 07:46:10AM +0100, Andrew Haley wrote:
> On 07/06/2013 04:58 AM, Jack Howarth wrote:
> > On Fri, Jul 05, 2013 at 05:25:47PM +0100, Andrew Haley wrote:
> >> 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.
> > 
> >    I assume you are doing this to create binary tarball
> > distributions which can be deployed on various linux distros,
> > correct? Isn't this rather dangerous as you are compiling libgcj
> > against the headers of some unknown libiconv release and then having
> > it linked against a completely different one when deployed in the
> > field.
> 
> It's never broken anything before.  Why would it do so now?
> 
> > Doesn't this require a lot of assumptions about the data structures
> > on libiconv calls not changing between the various releases? It
> > would seem to be safier if you just added an option to statically
> > link libiconv.a into libgcj if such a portable tarball release was
> > required.
> 
> It'd help a lot if you explained what problem you're trying to solve.
> "shared library best practices" doesn't quite do it.

The problem is that the current configury in libjava can't cope with the
case of building a multilib on a system has a fat x86_64/i386 libiconv
present in /usr/include and /usr/lib and a targeted libiconv in /sw/include
and /sw/lib that only exists as x86_64. The normal build handles this okay with just...

--with-libiconv-prefix=/sw

producing no linkages against the system libiconv shared library but if one uses...

--with-sysroot="/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk --with-libiconv-prefix=/sw

the x86_64 libraries of the multilib built with libgcj.spec end up linked to /usr/lib/libiconv.
I believe this is another permutation of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441
where the multilib build on x86_64-apple-darwin12 starts in the 32-bit i386 subdirectory (which
can't find a usable libiconv) and used to force that finding onto the toplevel x86_64 build which
should be able to find one but uses the cached information.
   My observation has been that this whole mess of cached libiconv settings in the multilib is
avoided if the linkage to libiconv is removed from libgcj.spec.in and placed on the libgcj shared
lib (which actually contains the undefined symbols being resolved anyway).
      Jack
ps I still don't see how you can defend totally decoupling the headers used for building against
a supporting library from the actual library itself. Isnt' that why soversioning was created in
the first place?
pps We have used the proposed patch in the past as the configury in libjava with regard to libiconv
has always been fragile.


> 
> Andrew.