Need Feedback: Technical Questions Regarding GCC/GCJ 3.3 Build under MSYS/MingW
Sun Mar 9 19:29:00 GMT 2003
>>>>> For that matter, the libgcj build exceeded Linux's command line limit
>>>>> 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. 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.
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.
That is, of course, a necessary condition, but by no means a sufficient
condition. If your application uses 6 shared objects, that at a certain
point in time have been distributed in 4 versions, you have 4^6=4096
possible combinations. Whatever you test in your development workbench has
no relevance at all, since you've only tested 1 of the 4096 possible
situations. You could as well skip such test. With time the sitation only
gets worse, since new versions of the same shared objects will be
distributed. With 5 versions, we have 5^6=15625. The whole idea of shared
objects is an attempt to defy the laws of gravity and flies in the face of
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.
More information about the Java