Need Feedback: Technical Questions Regarding GCC/GCJ 3.3 Build under MSYS/MingW

[Andrew Haley]

Erik Poupaert writes:
 > 
 > >>>>> For that matter, the libgcj build exceeded Linux's command
 > >>>>> line limit not too long ago, and build times shot up as a
 > >>>>> consequence.
 > 
 > Coming from the win32 world -- which has its own strange quircks -- I've
 > found it a strange way to enumerate the objects to link on the command line.
 > I would think that you could supply one or more object directory trees as
 > arguments to the linker, and that the linker would descend these, pick up
 > the object files, and link.

Even if you could do this, it would be unsafe.  We would not do it.

 > This enumeration of individual objects to link is obviously
 > unscalable.
 > 
 > There are some really good ideas that can be learned from the unix world,
 > but this excessive dependence on the command line isn't certainly one. You
 > can pipe things to the next command, but how do you get a real conversation
 > between two commands, with the second command providing feedback information
 > to the first one? The only possibility seems to be to fail with some
 > errorlevel; and that's it. There are so many application types that require
 > bi-directional communication. You could never organise such communication
 > through the command line.

In fact, this is trivial on any OS that supports named pipes.

Erik, please take a little bit of time to learn more before coming
here.

 > And then you have this excessive dependence on shared objects; it's even
 > worse than in the win32 world! It is based on the idea that backwards
 > compatibility can be achieved by maintaining support for the older APIs.

I don't think that anyone who has gone through the pain of finding and
patching all the executables that were statically linked against a
vulnerable libssl would agree.

 > But then these ideas are ingrained firmly in the designs of gcc, gcj, ld,
 > ar, and the whole toolchain. It will be a steep, uphill battle to improve
 > the toolchain within the existing framework of excessive dependency on
 > command line and shared objects.

We're not going to give up using shared libraries.  This is not
because threy're firmly ingrained but because in our opinion they are
the right tool for gcj.  IMO your opinion about shared libraries has
been thoroughly warped by their poor implementation on Windows.  But
we've argued this to death already.  I'm surprised you bring it up again.

Andrew.