This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
making static linkage useful (oh the horror!)
Andrew Haley <aph@redhat.com> writes:
> Trouble is, you're threatening to make static linkage useful!
Ah, the truth comes out!
I understand that the gcj folks would like to see libgcj.so/libgcj.dll
spread as far and wide as possible as part of your nefarious plot for
world domination. Making static linkage hard to use or bloated does
force people to distribute these libraries.
To be honest, I have the same motivations with my own project (XWT) in
attempting to increase the installed base of xwt.exe, so I can see
where you're coming from.
Unfortunately, as you've probably noticed based on the last few months
of mailing list traffic, the most common new use for gcj these days
seems to be people who want a .java->.exe converter. These people
really don't want to distribute a dll, especially not one that's
4-16MB (depending on stripping and compression).
> That means people will use it, and then ... we have support
> headaches.
If support headaches are really the only concern, perhaps we could
adopt a policy that static linkage is strictly an experimental,
unstable, use-at-your-own-risk feature, and not accept any PRs which
cannot be reproduced with dynamic linkage?
BTW, I also think it would be really cool if we could produce
statically linked binaries that would dlopen() libgcj.dll/libgcj.so
*if available* and use that library instead of the statically linked
classes. This way even statically linked binaries could take
advantage of updates to libgcj when the user installs a new version.
But if the user doesn't have libgcj, the app still works because it
has the required classes linked in. I'd be quite interested in
working on this, and I think it's quite possible with indirect
dispatch.
- a