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