"Scalability" Issues with the libgcj Makefile

Ranjit Mathew rmathew@hotmail.com
Mon Aug 26 21:30:00 GMT 2002


Hi,
 As an update on the "libtool" and "ar" issue, I
must mention that it was "solved" when I changed
the value of "max_cmd_len" throughout the libtool
script to something like "3000" - it then used
"piece wise linking" to create the final libgcj.a.
Another "scalability" issue (stack dump with the MSYS
make) came when I tried to install the final
GCJ/libgcj combo. Specifically, the problem was
in the "install-data-local" target of the Makefile
and was once again due to the use of $(shell ) within
a $(foreach ) that had a lot of header file names to
process.
Sincerely Yours,
Ranjit Mathew.
Ranjit Mathew wrote:
> Hi,
>> I'm (still) trying to build GCJ (GCC 3.2) with
> MinGW/MSYS on Windows and some of the more troublesome
> errors have been related to the "scalability" of the
> libgcj Makefile, considering the fact that it has so
> may object files (989 Java objects without the AWT classes!)
> to deal with.
>> Allow me to explain.
>> In a previous post, I had mentioned that the MSYS make
> was crashing ("stackdumping") on me. After a bit of
> fiddling around, I found it to be a result of this bit
> in the Makefile:
>> @: $(shell echo Creating list of files to link...) $(shell rm -f libgcj
> .objectlist || :) $(shell touch libgcj.objectlist) $(foreach 
> object,$(libgcj_la
> _OBJECTS) $(libgcj_la_LIBADD),$(shell echo $(object) >> libgcj.objectlist))
>> Replacing it with the equivalent (for the moment):
>> $(shell rm -f libgcj.objectlist)
> $(shell touch libgcj.objectlist)
> echo $(libgcj_la_OBJECTS) >>libgcj.objectlist
> echo $(libgcj_la_LIBADD) >>libgcj.objectlist
>> "fixes" the problem (though it is not necessarily a neat solution).
>> From the GNU Make manual:
>> "The shell function performs the same function that backquotes (``') 
> perform in most shells: it does command expansion. This means that it 
> takes an argument that is a shell command and returns the output of the 
> command."
>> The MSYS make is therefore trying to expand the output of
> all those $(shell ) invocations and adding them up to produce
> the final output, even though the libgcj build process is
> not at all interested in it. Unfortunately, it dies out in
> the process (no pun intended).
>> Another issue (for me) was the actual creation of the libgcj
> library, invoked by this bit in the Makefile:
>> $(libgcj_la_LINK) -objectlist libgcj.objectlist \
> ../boehm-gc/libgcjgc_convenience.la 
> ../libffi/libffi_convenience.la ../
> zlib/libzgcj_convenience.la \
> -rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
>> Once again, this results in a call to 'ar' with a command
> line that comprises not only the 989 classes I mentioned
> earlier, but the additional object files from boehm-gc,
> libffi, etc. as well. As a result, 'ar' also dies out
> with a pitiful "Invalid Argument" error (I have tried it
> out with fewer arguments, and therefore fewer object
> files, and it does work).
>> Again, since 'ar' is additive, we can break the process
> into more manageable chunks, "growing" the library till
> it has everything we need.
>> Sincerely Yours,
> Ranjit.
>>>>


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /