URL() problem

Warren Levy warrenl@cygnus.com
Fri Apr 9 18:50:00 GMT 1999


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.

My apologies for the terse answer but I got your mail just as I was
heading out and wanted to get you an answer asap.
--warrenl



More information about the Java mailing list