From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28951 invoked by alias); 6 Jul 2013 03:58:25 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 28939 invoked by uid 89); 6 Jul 2013 03:58:23 -0000 X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_GC,TW_IB autolearn=ham version=3.3.1 Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 06 Jul 2013 03:58:21 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id AB9FFB0076; Fri, 5 Jul 2013 23:58:19 -0400 (EDT) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id r663wJNY027280; Fri, 5 Jul 2013 23:58:19 -0400 Date: Sat, 06 Jul 2013 03:58:00 -0000 From: Jack Howarth To: Andrew Haley Cc: java-patches@gcc.gnu.org Subject: Re: [PATCH] link libgcj directly to libiconv to resolve symbols Message-ID: <20130706035819.GA22350@bromo.med.uc.edu> References: <20130705161058.GA15079@bromo.med.uc.edu> <51D6F38B.4000205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D6F38B.4000205@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2013-q3/txt/msg00004.txt.bz2 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. >