This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: question about old patch
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>
- Date: Wed, 10 Mar 2004 18:55:46 -0500
- Subject: Re: question about old patch
- References: <87hdwws250.fsf@fleche.redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Mar 10, 2004 at 04:39:23PM -0700, Tom Tromey wrote:
> Jakub, I have a question about this patch:
>
> 2004-01-20 Jakub Jelinek <jakub@redhat.com>
>
> * Makefile.am (lib_org_w3c_dom_la_LIBADD,
> lib_org_w3c_dom_la_LDFLAGS): New.
> (lib_org_xml_sax_la_LIBADD, lib_org_xml_sax_la_LDFLAGS): New.
> * Makefile.in: Rebuilt.
>
> Original post is here:
>
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02012.html
>
> Yesterday I looked into a bug report where gij crashed in certain
> circumstances. It turns out if gij tries to load lib-org-xml-sax.so,
> since this is linked against libgcj.so, we get duplicate registration
> of classes, causing a failure.
The class registration is done through library constructor?
If so, I'd like to know how you can get duplicate registration.
If a library is already loaded, dlopening it (or dlopening some library
which has it as dependency) will not run the constructors again.
> We can fix this by changing these libraries so that they don't depend
> on libgcj.so. But before doing that I'd like to understand why you
> changed these libraries to link against libgcj.so.
Not linking a shared library against its dependencies is a serious bug
for multiple reasons (symbol versioning, dlopen-ability, prelinking, ...).
Jakub