PR libgcj/40868 - ecjx should be build with host compiler

Dmitrijs Ledkovs dmitrij.ledkov@ubuntu.com
Tue Aug 17 13:32:00 GMT 2010


Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> Hello,
>
> * Andrew Haley wrote on Mon, Aug 16, 2010 at 11:37:00AM CEST:
>> -ecjx_LINK = $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS)
>> +ecjx_LINK = $(GCC_FOR_ECJX) -c -o $(am_ecjx_OBJECTS) $(top_srcdir)/$(ecjx_SOURCES) && $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS)
>
> Why should a _LINK variable (which is used for linking) contain -c?

I couldn't figure out making a custom ecjx_COMPILE command for ecjx.cc
only. Hence I've used a "hack" in _LINK.

> Why should -o be followed by a variable name that presumably contains
> several objects?
>

In theory, yes. In reality, no. ecjx.cc is an empty file, needed to
create an "empty" object such that libtool can link-it with all the libs
it needs to be linked.

> This hunk looks very wrong.  If it causes the right thing to happen,
> then in a very hacky way.
>

Yes, the hunk looks wrong, the real issue is deeper. How to tie in
ecj.jar into the automake/libtool build-system. The current way works
for native builds, but building regular cross fails since ecj.o becomes
"target" object type, instead of "build/host" object type.

I better test would be trying to build canadian-cross & reverse-cross
libjava. I'm not quite sure, but it should be broken now and this patch
may or may not fix those too.

With this patch I have managed to build build/host=i686-linux-gnu
target=i686-w64-mingw32 libjava & gcj.

I would be valuable to find who thought up of ecjx.cc and put more
comments into ecjx.cc 

I have even less clue than reviewers in this thread =)




More information about the Gcc-patches mailing list