This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [build, libjava] Support Sun symbol versioning in libjava
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Andrew Haley <aph at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Paolo Bonzini <bonzini at gnu dot org>
- Date: Fri, 02 Jul 2010 14:26:54 +0200
- Subject: Re: [build, libjava] Support Sun symbol versioning in libjava
- References: <yddy6dv6ve5.fsf@CeBiTec.Uni-Bielefeld.DE> <4C2DD7DC.5010301@redhat.com>
Andrew Haley <aph@redhat.com> writes:
> To begin with, your patch was *below* the .sig delimiter. People won't
> see it there.
I've never heard that being a problem.
> I have to admit I don't understand many of the issues here. There seem
> to be many changes to the Linux version, which I don't see the need for.
Actually no: I just introduce per-library variables where I need them
with Sun ld, but set them all to the same value as before for Linux.
> Did you test this on GNU/Linux ?
Not yet: no access. Perhaps via VirtualBox or the GCC test farm.
>> Besides, there are a couple of other shared libraries installed by
>> libjava, which may be internal implementation details and not usable by
>> end users. Perhaps they should be installed into $pkglibdir instead?
>> Currently, this affects libgij, libgcj-tools, libjvm, lib-gnu-awt-xlib,
>> and libgcj_bc. The maintainers should be able to easily decide where
>> this might apply.
>
> A couple of these are internal, but most not.
Could you point out which of the are supposed to be used by end users
with -l<lib>?
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University