This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: successful(?) build of libjava on mips-sgi-irix6.5
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Cc: Philip Goisman <goisman at physics dot arizona dot edu>, David dot Billinghurst at riotinto dot com, bryce at albatross dot co dot nz, java-discuss at sources dot redhat dot com, goisman at m5 dot physics dot arizona dot edu
- Date: 08 Feb 2002 22:32:25 -0200
- Subject: Re: successful(?) build of libjava on mips-sgi-irix6.5
- Organization: GCC Team, Red Hat
- References: <200202082123.g18LNjw36278@m5.physics.arizona.edu><yddsn8b8wcw.fsf@xayide.TechFak.Uni-Bielefeld.DE>
On Feb 8, 2002, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:
> Philip Goisman <goisman@physics.arizona.edu> writes:
>> Is there a solution to this error such that libgcj will get
>> built on mips-sgi-irix6.5, or, is it still true that libgcj still
>> cannot be built on mips-sgi-irix6.5?
> I've documented a workaround in
> http://gcc.gnu.org/install/specific.html#mips-sgi-irix6
> that allowed me to build libgcj on mips-sgi-irix6.[25]. Of course, the
> underlying problem should be fixed in libtool.
This could only be fixed in libtool if libtool got a chance to run.
Clearly, this is not the case, as it is make that is having trouble to
run a shell that would then invoke libtool.
Still, I wonder why the command line is so long. It appears to me
that it shouldn't be.
Clearly, whoever arranged for libgcj.objectlist to be created in a way
that didn't require GNU make missed this fact and introduced the very
problem I was trying to avoid, that could only be avoided by this
unfortunate dependence on GNU make, or by some major reworkings of the
Makefile.
If you have no idea of what I'm talking about, compare the code in the
mainline, that I wrote:
libgcj.la: $(libgcj_la_OBJECTS) $(libgcj_la_DEPENDENCIES)
@: $(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))
$(libgcj_la_LINK) -objectlist libgcj.objectlist \
@LIBFFI@ \
-rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
with what's in the branch:
libgcj.la: $(libgcj_la_OBJECTS) $(libgcj_la_DEPENDENCIES)
@echo $(libgcj_la_OBJECTS) > libgcj.objectlist;
@echo $(libgcj_la_LIBADD) >> libgcj.objectlist;
$(libgcj_la_LINK) -objectlist libgcj.objectlist \
../libffi/libfficonvenience.la \
-rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
Nothing that libtool could possibly do will make the second @echo,
with its huge argument list, executable as a single shell command. It
has to be broken up in multiple pieces, which is precisely what the
foreach construct with multiple shell commands does. Unfortunately,
it depends on GNU make.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer