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

[Jeff Sturm]

On Sat, 8 Mar 2003, Mohan Embar wrote:
>   However, the latter half of the libgcj build has the calls to gcj
>   wrapped by libtool. What would be the best approach to
>   disentangle these?

You could do something similar, e.g. "gcj -c *.java".  I don't know if
libtool would get in the way or not.

> - libtool's -objectlist flag sources a gazillion .lo files and
>   flails away at them. This process is slow on Linux and
>   excruciating on MingW. I've seen in other places how
>   gcc will whip up a tiny executable and then run it
>   (cf. gengtype[.exe]). Since we've got a gcc somewhere,
>   couldh't we use this approach for the -objectlist flag?

Libtool developers once started a compiled version.  I don't know if it
went anywhere.

Given that libtool consists of so many set and string operations, C isn't
a very natural language for it.  Java might be.  But coding libtool, or an
equivalent, in Java may require a JRE for bootstrapping libgcj, which
would be a pain.

>   What do you think? Am I nuts?

No, but libtool is making you a little nuts, perhaps.  You're not the
first.

> - Unlike UNIX, where you can pass the entire population
>   of Switzerland on the command line, Windows and MingW
>   seem less tolerant in this regard. And with libtool, the consequences
>   of not being able to pass everything to ar in one go means you have
>   to take an additional hit of sorting the object file list and
>   dealing with duplicates as you invoke ar multiple times.

For that matter, the libgcj build exceeded Linux's command line limit not
too long ago, and build times shot up as a consequence.

>   And what about using the same file list approach with
>   gcj.exe / jc1.exe?

Sounds like a great idea.

Trouble is, libgcj needs libtool for portability.  I don't know a better
tool for the job.  Apart from joining the libtool development community
and helping out, what can be done?

Jeff