Friday, May 6, 2005, 8:06:49 AM, you wrote: AH> Rutger Ovidius writes: >> Friday, May 6, 2005, 1:33:32 AM, you wrote: >> >> 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.
AH> Yes, which is why we're redesigning the ABI so that compiled apps AH> won't depend on a specific release of the library. We're fixing the AH> real problem rather than depending on nasty kludges like static AH> linking. It would be a feature; a kludge seems to be your opinion, and no one would depend upon it. I don't think having the option to link static would affect the natural java way(?) of linking dynamically. >> 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. AH> Is it really? There are users out there insane enough to be passing AH> around precompiled binaries of small utils? I don't need to pass it around to anyone else to experiene the limitation. The utilities can be moved on to systems on which I do not have access to install the latest gcc globally. I must also include a large libgcj each time. >> This isn't really possible without static linking. AH> But Java isn't compatible with static linking. Java is, by its very AH> nature, a dynamic language, where classes invoke and even generate AH> other classes on the fly. There is no way when linking to determine AH> what set of libraries is required. This is a simple fact, and no AH> amount of declaring " this is what users want!" is going to change AH> it. I didn't know that java had a nature. It has features. Some features will work when it is implemented in a certain way and some won't. Compiling natively with GCJ adds the opportunity to add features. Static linking would be a feature. I don't think "natural java" supports CNI, but this is a nice feature that compiling with gcj adds. >> Sometimes I see a great divide between the developers of gcj, and >> the actual users of it. AH> Spare us the ad homs, please. I think I can freely express a personal viewpoint just like you have above. Thank you.
