This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: static linking
- To: jeff dot sturm at commerceone dot com
- Subject: Re: static linking
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Wed, 06 Dec 2000 14:00:13 +1300
- CC: java-discuss at sources dot redhat dot com
- References: <3A2D85B3.E57E33A8@appnet.com>
Jeff Sturm wrote:
> 1) libsupc++ doesn't get linked by gcj
>
> This seems like an oversight. Since libgcj.so is linked against libsupc++,
> normal (shared) linking just happens to work. I "fixed" it by adding supc++ to
> libgcj.spec. I'll see if I can cobble together a patch.
gcj shouldn't need to do anything special to get the supc++ stuff, it should all
be put into libgcj.a, the same way it gets built into libstdc++. libtool seems to
do this automatically for me. Does it not work for you?
> 2) classes loaded dynamically (via Class.forName) don't get linked
>
> I don't see any good solution. I got around it by linking the following dummy
> class into my executable, but YMMV:
>
> class Dummy {
> java.security.cert.Certificate dummy1;
> gnu.gcj.protocol.file.Handler dummy2;
> gnu.gcj.protocol.http.Handler dummy3;
> gnu.gcj.protocol.jar.Handler dummy4;
> }
There's a linker flag which will force it to link in certain classes. Its a bit
ugly because you have to pass the mangled classname. Try something like
-Wl,-u,_Q53gnu3gcj8protocol3jar7Handler.class$ (untested).
The best solution, I think, would be to make a compiler option that allows you to
do this more easily. eg
"--link=gnu.gcj.protocol.jar.Handler,gnu.gcj.protocol.http.Handler" or something.
regards
[ bryce ]