From: Andrew Haley <aph@redhat.com>
To: Jack Howarth <howarth@bromo.med.uc.edu>
Cc: java-patches@gcc.gnu.org
Subject: Re: [PATCH] link libgcj directly to libiconv to resolve symbols
Date: Sat, 06 Jul 2013 06:46:00 -0000 [thread overview]
Message-ID: <51D7BD32.7050509@redhat.com> (raw)
In-Reply-To: <20130706035819.GA22350@bromo.med.uc.edu>
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.
next prev parent reply other threads:[~2013-07-06 6:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 16:11 Jack Howarth
2013-07-05 16:25 ` Andrew Haley
2013-07-06 3:58 ` Jack Howarth
2013-07-06 6:46 ` Andrew Haley [this message]
2013-07-06 11:19 ` Jack Howarth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51D7BD32.7050509@redhat.com \
--to=aph@redhat.com \
--cc=howarth@bromo.med.uc.edu \
--cc=java-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).