This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [build, libjava] Support Sun symbol versioning in libjava


On 07/02/2010 01:26 PM, Rainer Orth wrote:
> 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.

Glad to be of service.  :-)

>> 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.

Ah, I see now.

>> 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>?

lib-gnu-awt-xlib no, but that's loaded with dlopen() so has to be on the
default path AFAIK.  I'm not sure about libgij.  libgcj-tools and libjvm,
yes.  libgcj_bc, probably not.

I think Tom Tromey might be able to answer this better than me.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]