Trying to embed gnu.xml.dom.DomDocumentBuilderFactory

[David Daney]

Andrew Haley wrote:
> David Daney writes:
>  > Mohsen Saboorian wrote:
>  > > On 4/21/07, Andrew Haley <aph@littlepinkcloud.com> wrote:
>  > >> Mohsen Saboorian writes:
>  > >>  > On 4/21/07, Andrew Haley <aph-gcc@littlepinkcloud.com> wrote:
>  > >>  > > Mohsen Saboorian writes:
>  > >>  > >  > I filled a bug report:
>  > >>  > >  > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31647
>  > >>  > >  >
>  > >>  > >  > Andrew, newing DomDocumentBuilderFactory workaround didn't 
>  > >> work for
>  > >>  > >  > me. Do you know any other workaround ;)?
>  > >>  > >
>  > >>  > > Did you follow my suggestion?
>  > >>  > >
>  > >>  >
>  > >>  > Yes, and there was some entries for both
>  > >>  > gnu.xml.dom.DomDocumentBuilderFactory and gnu.xml.dom.DomImpl.
>  > >>
>  > >> No, you need the dump for gnu.xml.dom.DomDocumentBuilderFactory and
>  > >> gnu.xml.dom.DomImpl.  It's *their* dependencies that are causing the
>  > >> problems.
>  > >>
>  > >> Andrew.
>  > >>
>  > >
>  > > As you see in attachments, there is no dependency between two classes
>  > > DomDocumebtBuilderFactory and DomImpl.
>  > >
>  > > But what about NoClassDefFounError in my class in which I explicitly
>  > > new'd DomImpl?
>  > Try running under gdb with a breakpoint in the NoClassDefFoundError 
>  > constructor.  You can then walk up the stack a bit and see which class 
>  > it is looking for.
>
> Yes.  
>
> Something has just dawned on me: all the XML stuff is built with
> indirect dispatch in the current libgcj, and that will break
> everything when linking statically!
>
> Mohsen, we build the XML stuff with indirect dispatch so that it can
> easily be dynamically replaced, but this is bad for you.  Edit
> scripts/makemake.tcl so that lines like these are removed:
>
> set package_map(gnu/xml/util) bc
> set package_map(javax/xml) bc
>   
We already use different options (-fPIC, etc) for shared objects.  We 
should probably also make the BC ABI dependent on this also.

David Daney