This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with Mohans GCJ 20030522 build


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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]