Re: gcj sending -foutput-class-dir to cc1

[LLeweLLyn Reese <llewelly at lifesupport dot shutdown dot com>]

Matt Mello <alien at spaceship dot com> writes:

> Hello, everyone.
> 
> This is my first time to post to this list, so please forgive any
> mistakes (like posting to the wrong list)!  I searched the archives,
> but could not find this problem in them.
> 
> I'm having a problem running gcj.  When it invokes cc1, it is passing
> the -foutput-class-dir option to it.
> 
> Any idea how to remedy this?  I realize that cc1 can't handle
> -foutput-class-dir, but I don't know why gcj is sending it.

To me, this sounds like a bug. I am not completely confident of this,
    but I think you should consider reporting this as a bug, as well
    as posting here in search of a work-around.

I don't know of a work-around for this.

> 
> Please reply to my email address, too, as even though I subscribed to
> this list, I have not received my confirmation yet.
> 
> INFO:
> 
> I just downloaded, built, and installed the entire gcc build with
> suffix of 3.2.2 and prefix of /usr/local/gcc3.2.2.  It all seems to be
> working fine.  The correct things are getting invoked, so far as I can
> tell.
> 
> root at spore:/home/mattm/prj/src
> $ gcc3.2.2 --version
> gcc3.2.2 (GCC) 3.2.2
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Here is the output of the command that borks:
> $ gcj3.2.2 -v -fno-asm
> --CLASSPATH=.:javalibs/ecs-1.3.2.jar:javalibs/jcert.jar:javalibs/jnet.jar:javalibs/jsse.jar:javalibs/eteks.jar:javalibs/jsdk.jar:javalibs/comm.jar:javalibs/ccc_ssl.jar:javalibs/tools.jar
> -o paymateclient --main=net.paymate.terminalClient.testpos -d
> classes.gcj @all.list
> Reading specs from
> /usr/local/gcc3.2.2/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs
> Reading specs from
> /usr/local/gcc3.2.2/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../libgcj.spec
> rename spec lib to liborig
> Configured with: ../gcc-3.2.2/configure --prefix=/usr/local/gcc3.2.2
> --program-suffix=3.2.2
> Thread model: posix
> gcc version 3.2.2
>   /usr/local/gcc3.2.2/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/jc1 all.list
> -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc
> -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase
> all.list -g1 -version -fno-asm
> -fclasspath=.:javalibs/ecs-1.3.2.jar:javalibs/jcert.jar:javalibs/jnet.jar:javalibs/jsse.jar:javalibs/eteks.jar:javalibs/jsdk.jar:javalibs/comm.jar:javalibs/ccc_ssl.jar:javalibs/tools.jar
> -foutput-class-dir=classes.gcj -ffilelist-file -o /tmp/ccXzYjNn.s
> GNU Java version 3.2.2 (i686-pc-linux-gnu)
>          compiled by GNU C version 3.2.2.
> Class path starts here:
>      ./
>      javalibs/ecs-1.3.2.jar/ (zip)
>      javalibs/jcert.jar/ (zip)
>      javalibs/jnet.jar/ (zip)
>      javalibs/jsse.jar/ (zip)
>      javalibs/eteks.jar/ (zip)
>      javalibs/jsdk.jar/ (zip)
>      javalibs/comm.jar/ (zip)
>      javalibs/ccc_ssl.jar/ (zip)
>      javalibs/tools.jar/ (zip)
>      /usr/local/gcc3.2.2/share/java/libgcj-3.2.2.jar/ (system) (zip)
>   as -V -Qy -o /tmp/ccgEFwUu.o /tmp/ccXzYjNn.s
> GNU assembler version 2.11.93.0.2 (i386-redhat-linux) using BFD
> version 2.11.93.0.2 20020207
>   /usr/local/gcc3.2.2/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/jvgenmain
> net.paymate.terminalClient.testposmain /tmp/cciA2MZl.i
>   /usr/local/gcc3.2.2/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/cc1
> /tmp/cciA2MZl.i -quiet -dumpbase
> net.paymate.terminalClient.testposmain.c -g1 -version -fno-asm
> -foutput-class-dir=classes.gcj -fdollars-in-identifiers -o
> /tmp/ccXzYjNn.s
> cc1: unrecognized option `-foutput-class-dir=classes.gcj'
> GNU CPP version 3.2.2 (cpplib) (i386 Linux/ELF)
> 
> 
> GCJ seems to do the majority of the compiling of the java before it
> calls the assembler.  The assembler seems to work fine, then when GCJ
> calls cc1, cc1 complains about the -foutput-class-dir option.
> 
> Hope this is legible.  The wrapping is terrible.
> 
> Thanks for any help you can give!
> 
> -- 
> Matt Mello