Re: URL() problem

[Bryce McKinlay <bryce@albatross.co.nz>]

Warren Levy wrote:

> On Sat, 10 Apr 1999, Urban Widmark wrote:
>
> > but nm shows traces of 'gnu.gcj.protocol.http.Handler' in libgcj.a (the
> > installed one), such as:
> > 00000000 T __Q53gnu3gcj8protocol4http7Handler
> >
> > However nm does not show anything in my program, but it does show other
> > parts of the gnu.* packages. I'm thinking that this is a linkage problem,
> > where the code from Handler.o is not included since it is not directly
> > referenced, only loaded dynamically by the URL class.
>
> Try adding '-Wl,-u,_CL_Q53gnu3gcj8protocol4http7Handler -lnsl -lsocket'
> to your link line and you should see better results.  Depending on your
> platform, you may have to link with libs other than nsl or socket.
>
> The problem is due to the spec'ed design for URL handling having to
> load the proper protocol handler class from a search at runtime.  Since
> it isn't an unresolved reference at link time, the linker won't bring the
> protocol handler in from libgcj, hence the need to force the linker to pull
> it in.  I got the mangled class name via nm (as you did) but the symbol you
> listed in your email is just the constructor I believe.  Look for the
> symbol for the data section ('D') to get the right name.  I believe
> you could also use __vt_Q53gnu3gcj8protocol4http7Handler in this case.
>
> We're aware of the awkwardness of this and are investigating ways
> to link/access these kinds of unreferenced classes.

The obvious solution/workaround here (on platforms that support it) is simply
to compile libgcj as a shared library. This way, all required symbols get
found at runtime, and you get the added bonus of having nice small binaries
and reduced memory usage when running multiple java binaries simultaneously.

libgcj's configure script doesn't seem to support an "--enable-shared" option
(cygnus guys: can this be added?) - I just built libgcj.so and libgcjgc.so by
hand and deleted the original .a files.

regards

  [ bryce ]