Friday, May 6, 2005, 1:33:32 AM, you wrote: AH> Rutger Ovidius writes: >> Thursday, May 5, 2005, 1:16:05 PM, you wrote: >> >> RH> On Thu, May 05, 2005 at 04:57:48PM -0300, Alexandre Oliva wrote: >> >> The savings of creating static libraries would be small if we >> >> refrained from building non-PIC object files. >> >> RH> But still largely useless. Who in their right mind is going to >> RH> use an 83MB static library when a shared library is available. >> >> Everyone on win32 builds libgcj static, and probably wants to keep it >> that way if they plan to distribute their apps. >> >> What would be the point of distributing a giant shared library with >> every application compiled with gcj, especially when awt/swing only >> hook into gtk? >> >> I don't think libgcj.dll will ever be standard on any distribution of >> win32, yet the many advantages of compiling java code to fast, native >> executables apply on this platform.
AH> I don't think that anyone is proposing to drop static libraries on AH> Win32. Win32 systems have their own requirements that make static AH> libs preferable in some cases. On GNU systems, however, static libs AH> make no sense at all for the Java language. One of the first things I had hoped for from gcj was static linking (except for libc) on GNU systems. There is new era of shared library hell and it seems to only apply to libgcj. Having to manually pare down the libgcj .so and distribute it with apps seems necessary; expecting target users of a new gcj compiled app to have an absolutely up-to-date and compatible libgcj.so (probably compiled with small patches along the way to make this specific app work) is not reasonable. Plus, the release cycle of gcc will never match the development speed of libgcj. There are die hard followers of gcc that do have up to date systems, but the vast majority do not and never will. Java is a simple language, used as the intro learning language in most universities that I know of. Not having to plan memory management like c++ motivates very fast development. Compiling small utils with it and having them be portable, even on GNU systems, is an incredible selling point. This isn't really possible without static linking. Sometimes I see a great divide between the developers of gcj, and the actual users of it. It seems to only target the server setting, or the user who wishes to compile existing apps and only run them on their own system. This target could be much wider in scope with static linking.
