RE: libgcc_s.so.1 and libgcj.so.4

["Erik Poupaert" <erik dot poupaert at chello dot be>]

>>>> In practice it doesn't change very often, but I
>>>> make no guarantees.

At this point, I believe there is a need to reduce the perceived complexity
of gcj.

The complexity of gcj is primarily the result of its incredible flexibility
and, of course, not only of the fact that it still requires quite a bit of
work. We can expect the latter to improve, but not immediately.
Realistically, it is a medium to long term proposition, I guess.

Therefore, I think, that by furthering a particular, specialized strand of
using gcj, with less flexibility, I could create a relatively simplified
view on the toolkit, which would promote it with people who would otherwise
shun away from it.

That's why I want to create these front end tools, that will follow a
particular compilation and linking strategy in which libgcj would be linked
statically, and as you suggested, libgcc_s rather dynamically; on linux. On
win32 all of it would still be linked statically; until the platform's
importance has sufficiently faded away. At such point, I will probably drop
support for it. But then again, on the long run we're all dead :)

People who intend to use these front end tools, but need more flexibility
will -- evidently -- always have the option to invoke gcj directly, for
special cases or in areas in which they need the underlying gcj flexibility
to obtain a better end product.

I would, of course, need to collaborate closely with the people managing the
integration of gcj, gcc, and ld and obtain information in time, in order to
avoid disappointments for the users of such front end tools.