Problems with Mohans GCJ 20030522 build
Ranjit Mathew
rmathew@hotmail.com
Wed Jun 4 05:11:00 GMT 2003
> I have discussed this with Mohan, but we haven't figured out
> why GCJ as of >20030409 must have thisiscool-gcc\gcc-3.3\bin
> in the path.
Probably because these have the "mingw-local" patches
applied...
> - gcj fails if it is not in the path
[...]
> [apply] gcj.exe: installation problem, cannot exec `as': No such
> file or directory
[...]
> - If I fix the path, it dies with:
>> [apply] com/cyviz/xyzmodem/Upload.java:164: warning: unreachable
> bytecode from 221 to before 224
> [apply] Error: 0-bit reloc in dll
> [apply] Error: 0-bit reloc in dll
The latter seems to be a bug in recent MinGW binutils
on large objects/DLLs:
http://article.gmane.org/gmane.comp.gnu.mingw.user/7425
The former also seems like a bug (to me) in "mingw local".
(Only Danny can say for sure, though.)
In particular, in FSF 3.3 sources (but not any more
in 3.4 in CVS), "gcc/config/i386/cygwin.h" overrides
GCC's "relocatability" by hard-coding paths if
"WIN32_NO_ABSOLUTE_INST_DIRS" is not defined. This
is defined by "gcc/config/i386/mingw32.h" which
#includes the former - so Cygwin GCC becomes
hardwired to a folder location, while MinGW GCC
remains relocatable.
Danny must have had a good reason for doing this
in "mingw local" - or maybe it's just an oversight - I
don't know and I will wait for Danny's comment on this.
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/
More information about the Java
mailing list