Re: GCC 4.1: Buildable on GHz machines only?

[Rutger Ovidius <r_ovidius at eml dot cc>]

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.