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

[Mohan Embar]

Hi GCC Experts,

Having limped through this build, I find myself buzzing with questions and
thoughts. Most of them are probably due to my inexperience and I might
have gotten some facts wrong.

Can you help me answer them? Am I posting these to the proper mailing list?

- Tom had alluded to being able to build everything in one fell swoop, which
  would considerably reduce build time:

  http://gcc.gnu.org/ml/java/2003-02/msg00590.html

  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?

- 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?
  In other words, we'd generate an executable on the
  fly that would whip through these .lo files and produce
  non_pic_objects.txt and pic_objects.txt in the libjava
  build directory which libtool could then read into
  variables and iterate through.

  In the case of a cross compiler, we could have the
  thing that built the cross compiler also produce this
  executable and stash it away somewhere that the
  cross compiler could get to it.

  What do you think? Am I nuts?

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

  Before I took the more conservative approach of setting
  a smaller maximum command line length on MingW, I
  enhanced ar.exe to take a file list and made libtool
  dump its object file list to a text file which ar.exe read in.
  It worked beautifully. This technique is used by many
  Windows programs.

  What are your thoughts on accommodating
  command-line-length-challenged build environments in this
  way (using file lists)? And if you're not averse to this,
  what is the best way to check for the existence of
  such an ar-variant? I haven't thought of a really nice
  way of doing this, but was thinking about things like
  "ar --supports filelist" returning some known exit
  code... Bleah! Help me out here!

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

Thanks in advance for your feedback.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/