Re: GCC 4.1: Buildable on GHz machines only?

[Andrew Haley <aph at redhat dot com>]

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.

Yes, which is why we're redesigning the ABI so that compiled apps
won't depend on a specific release of the library.  We're fixing the
real problem rather than depending on nasty kludges like static
linking.

 > 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.

That too.

 > 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.

Is it really?  There are users out there insane enough to be passing
around precompiled binaries of small utils?

 > This isn't really possible without static linking.

But Java isn't compatible with static linking.  Java is, by its very
nature, a dynamic language, where classes invoke and even generate
other classes on the fly.  There is no way when linking to determine
what set of libraries is required.  This is a simple fact, and no
amount of declaring " this is what users want!"  is going to change
it.

 > Sometimes I see a great divide between the developers of gcj, and
 > the actual users of it. 

Spare us the ad homs, please.

Andrew.