Forward declaration of classes needed when using GCJ?

Forward declaration of classes needed when using GCJ?

[Andrew W]

Consider the following two classes placed in files 
./net/mydomain/core/ClassA.java and
./net/mydomain/core/ClassB.java respectively:

package net.mydomain.core;
public class ClassA
{

public static void main(String[] args) throws Exception
{
ClassB classb = new ClassB();
}

}


package net.mydomain.core;
public class ClassB
{


}

If I compile this using the 'normal' Java compiler like this:
javac ./net/mydomain/core/ClassA.java ./net/mydomain/core/ClassB.java

it works fine.

Using the GCJ command:

gcj --main=ClassA ./net/mydomain/core/ClassA.java 
./net/mydomain/core/ClassB.java

produces the error:

./net/mydomain/core/ClassA.java:8: error: Type ‘ClassB’ not found in the 
declaration of the local variable ‘classb’.
ClassB classb = new ClassB();

Under C++ you would use an include of the header file for ClassB and a 
forward declaration to solve this, whats the solution for Java classes 
under GCJ?

I should point out this is a compile-time syntax error not a linker 
error. Compiling ClassB separately and then passing it the .o file wont 
solve it. There needs to be some way of forward declaring ClassB inside 
ClassA.java.

Thanks
Andrew

Re: Forward declaration of classes needed when using GCJ?

[David Daney]

Andrew W wrote:
> Consider the following two classes placed in files 
> ./net/mydomain/core/ClassA.java and
> ./net/mydomain/core/ClassB.java respectively:
> 
> package net.mydomain.core;
> public class ClassA
> {
> 
> public static void main(String[] args) throws Exception
> {
> ClassB classb = new ClassB();
> }
> 
> }
> 
> 
> package net.mydomain.core;
> public class ClassB
> {
> 
> 
> }
> 
> If I compile this using the 'normal' Java compiler like this:
> javac ./net/mydomain/core/ClassA.java ./net/mydomain/core/ClassB.java
> 
> it works fine.
> 
> Using the GCJ command:
> 
> gcj --main=ClassA ./net/mydomain/core/ClassA.java 
> ./net/mydomain/core/ClassB.java

That should be:
gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
./net/mydomain/core/ClassB.java

David Daney

Re: Forward declaration of classes needed when using GCJ?

[David Daney]

Never respond directly to me.  Keep the original mailing list(gcc-help@) 
  on the CC list.

Andrew W wrote:
> Fair enough but that doesnt actually address the problem. Its ClassB it 
> doesnt like.
> 

It likes it just fine.  I successfully compiled your exact code on my 
Fedora Core 8 system using this command line:

> 
> David Daney wrote:
>>
>> That should be:
>> gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
>> ./net/mydomain/core/ClassB.java
>>

David Daney

Re: Forward declaration of classes needed when using GCJ?

[Andrew W]

Fair enough but that doesnt actually address the problem. Its ClassB it 
doesnt like.

David Daney wrote:
>
> That should be:
> gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
> ./net/mydomain/core/ClassB.java
>
> David Daney
>
> ______________________________________________________________________
>

Re: Forward declaration of classes needed when using GCJ?

[David Daney]

Andrew W wrote:
> Fair enough but that doesnt actually address the problem. Its ClassB it 
> doesnt like.
> 

You are probably using an older gcj.  You didn't say which version.

Try setting the classpath for gcj, perhaps it cannot find the other class.

David Daney


> David Daney wrote:
>>
>> That should be:
>> gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
>> ./net/mydomain/core/ClassB.java
>>
>> David Daney
>>
>> ______________________________________________________________________
>>
> 

Re: Forward declaration of classes needed when using GCJ?

[Andrew W]

Interesting you got it to work with Fedora.
Im using the version that comes with Ubuntu 7.04 which is has the 
version string.

gcj (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu5)


Thanks David

Andrew

Re: Forward declaration of classes needed when using GCJ?

[Andrew Haley]

Andrew W wrote:
> Interesting you got it to work with Fedora.
> Im using the version that comes with Ubuntu 7.04 which is has the 
> version string.
> 
> gcj (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu5)

Works for me too:

zebedee:~ $ gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java ./net/mydomain/core/ClassB.java
zebedee:~ $ gcj --version
gcj (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.

Andrew.

Re: Forward declaration of classes needed when using GCJ?

[Andrew W]

OK I've solved  the problem when you've just got the two simple classes 
A & B. It seems is obscurely fussy about the current working directory.

It insists the current directory is the root of the project and you 
specify the .java files as a sub path below that it will NOT allow you 
to have the package dir containing the .java  files as the current 
directory. i.e

cd /path/to/project

gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
./net/mydomain/core/ClassB.java

WILL work

cd /path/to/project/net/mydomain/core/

gcj --main=net.mydomain.core.ClassA ./ClassA.java ./ClassB.java

will NOT

Anyway.

If you then try linking against jar files using --classpath= you're back 
to square 1.

Taking the above example (the 1st one) if you copy any  .JAR file to 
/path/to/project/

 then do

gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
./net/mydomain/core/ClassB.java --classpath='./lo4j-1.2.8.jar'

you get the same error about not recognising ClassB.

Even appending the current dir onto the end of the classpath doesnt 
solve it.

Any ideas?

Regards
Andrew

Building cross compiler for x86_64

[Frank W. Miller]

OK, so I'm off trying to build the x86_64 cross toolchain.  My host is
FC8 on a PC.

binutils-2.18 builds fine.

configure --target=x86_64-elf
make
make install

This gets me a nice set of tools in /usr/local/x86_64-elf/bin

I then try to build gcc-4.2.3

I tried:

configure --prefix=/usr/local --target=x86_64-elf
make all-gcc

This gets me an error saying x86_64-elf is not a supported target.  I
think tried substituting make all-gcc with make -k (after deleting the
source tree and starting over).  I get this error somewhere down the
line:

source='../.././libdecnumber/decimal128.c' object='decimal128.o'
libtool=no gcc  -I../.././libdecnumber -I.  -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
-Wno-long-long  -I../.././libdecnumber -I.
-c ../.././libdecnumber/decimal128.c
rm -f libdecnumber.a
ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o
decimal64.o decimal128.o
ranlib libdecnumber.a
make[2]: Leaving directory
`/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/libdecnumber'
make[1]: Target `all-host' not remade because of errors.
make[1]: Target `all-target' not remade because of errors.
make[1]: Leaving directory `/home/fwmiller/Desktop/gcc-4.2.3'
make: *** [all] Error 2


Can anyone comment?

Thanks,
FM

Re: Forward declaration of classes needed when using GCJ?

[Andrew Haley]

Andrew W wrote:

> If you then try linking against jar files using --classpath= you're back 
> to square 1.
> 
> Taking the above example (the 1st one) if you copy any  .JAR file to 
> /path/to/project/
> 
> then do
> 
> gcj --main=net.mydomain.core.ClassA ./net/mydomain/core/ClassA.java 
> ./net/mydomain/core/ClassB.java --classpath='./lo4j-1.2.8.jar'
> 
> you get the same error about not recognising ClassB.
> 
> Even appending the current dir onto the end of the classpath doesnt 
> solve it.
> 
> Any ideas?

Last time, two of us tried to duplicate your problem and failed.  It seems that
you didn't really describe what your problem actually was, so it worked for
us but not for you.  Could you please produce a test case, in a tarfile that
we can upack, and the exact command that you want us to try?  That way, we'll
at least be doing the same thing.  Also, we need to know which version of gcj you
used.

Andrew.

Re: Building cross compiler for x86_64

[Brian Dessent]

"Frank W. Miller" wrote:

> This gets me an error saying x86_64-elf is not a supported target.  I

I think you'll need to use a more recent version.  The support for bare
metal x86_64 wasn't added until r127798:
<http://gcc.gnu.org/viewcvs?view=rev&revision=127798>.  You could
probably just apply that patch to whatever version you're using.

> source tree and starting over).  I get this error somewhere down the
> line:
> 
> source='../.././libdecnumber/decimal128.c' object='decimal128.o'
> libtool=no gcc  -I../.././libdecnumber -I.  -g -O2 -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
> -Wno-long-long  -I../.././libdecnumber -I.
> -c ../.././libdecnumber/decimal128.c
> rm -f libdecnumber.a
> ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o
> decimal64.o decimal128.o
> ranlib libdecnumber.a
> make[2]: Leaving directory
> `/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/libdecnumber'
> make[1]: Target `all-host' not remade because of errors.
> make[1]: Target `all-target' not remade because of errors.
> make[1]: Leaving directory `/home/fwmiller/Desktop/gcc-4.2.3'
> make: *** [all] Error 2

That's not the error per se.  The actual error was earlier in the
process, but because of -k it kept continuing to build things that
didn't depend on the makefile target that errored.  So the above doesn't
really say anything, other than that something went wrong earlier.

BTW you're definitely going to want to disable things like libmudflap,
libssp, libdecnumber, libgomp, etc. if any of them turn out to be
enabled by default.

Brian

RE: Building cross compiler for x86_64

[Frank W. Miller]

Thanks for the reply.

I'm building 4.2.3 which was release on 2/1/08, 2 weeks ago.  Are you saying
there a more recent version that has that in it?

I'll send another email without the -k so it bombs at the first error.

How do I disable the building of the libs you are mentioning?

Thanks,
FM


-----Original Message-----
From: Brian Dessent [mailto:brian@dessent.net] 
Sent: Friday, February 15, 2008 4:59 PM
To: Frank W. Miller
Cc: gcc-help
Subject: Re: Building cross compiler for x86_64

"Frank W. Miller" wrote:

> This gets me an error saying x86_64-elf is not a supported target.  I

I think you'll need to use a more recent version.  The support for bare
metal x86_64 wasn't added until r127798:
<http://gcc.gnu.org/viewcvs?view=rev&revision=127798>.  You could
probably just apply that patch to whatever version you're using.

> source tree and starting over).  I get this error somewhere down the
> line:
> 
> source='../.././libdecnumber/decimal128.c' object='decimal128.o'
> libtool=no gcc  -I../.././libdecnumber -I.  -g -O2 -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
> -Wno-long-long  -I../.././libdecnumber -I.
> -c ../.././libdecnumber/decimal128.c
> rm -f libdecnumber.a
> ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o
> decimal64.o decimal128.o
> ranlib libdecnumber.a
> make[2]: Leaving directory
> `/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/libdecnumber'
> make[1]: Target `all-host' not remade because of errors.
> make[1]: Target `all-target' not remade because of errors.
> make[1]: Leaving directory `/home/fwmiller/Desktop/gcc-4.2.3'
> make: *** [all] Error 2

That's not the error per se.  The actual error was earlier in the
process, but because of -k it kept continuing to build things that
didn't depend on the makefile target that errored.  So the above doesn't
really say anything, other than that something went wrong earlier.

BTW you're definitely going to want to disable things like libmudflap,
libssp, libdecnumber, libgomp, etc. if any of them turn out to be
enabled by default.

Brian

Re: Building cross compiler for x86_64

[Brian Dessent]

"Frank W. Miller" wrote:

> I'm building 4.2.3 which was release on 2/1/08, 2 weeks ago.  Are you saying
> there a more recent version that has that in it?

Oh, right, I see how that would be confusing.  That patch was to the
trunk, and since it isn't a regression it probably will never be
backported to any branches so it won't be in any 4.2 release.  You can
try applying the change yourself to 4.2, you can try a 4.3 snapshot, or
abandon the idea of using the bare metal target and pick an existing
target that is just "close enough" to whatever kernel you're using.  It
seems rather hackish to me to build a e.g. linux targeted compiler if
the target isn't linux at all, but if it's just for doing purely
freestanding code I suppose it wouldn't be too wrong.

> How do I disable the building of the libs you are mentioning?

Each of those can be specified as e.g. --disable-libmudflap.

Brian

Re: Building cross compiler for x86_64

[Frank W. Miller]

I tried recompiling both binutils and gcc using x86_64 as the target as
follows:

binutils:

configure --target=x86_64-pc-linux
make
make install

This works fine.  Then gcc:

configure --prefix=/usr/local --target=x86_64-pc-linux
--enable-languages="c"
make all-gcc

This fails.  I get the following error:

/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/gcc/xgcc
-B/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/gcc/
-B/usr/local/x86_64-pc-linux/bin/ -B/usr/local/x86_64-pc-linux/lib/
-isystem /usr/local/x86_64-pc-linux/include
-isystem /usr/local/x86_64-pc-linux/sys-include -O2  -O2 -g -O2
-DIN_GCC -DCROSS_COMPILE -DNATIVE_CROSS   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc
-I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
-I../.././gcc/../libdecnumber -I../libdecnumber -fexceptions
-fvisibility=hidden -DHIDE_EXPORTS -c ../.././gcc/unwind-dw2.c -o
libgcc/./unwind-dw2.o
In file included from ./gthr-default.h:1,
                 from ../.././gcc/gthr.h:114,
                 from ../.././gcc/unwind-dw2.c:42:
../.././gcc/gthr-posix.h:43:21: error: pthread.h: No such file or
directory
../.././gcc/gthr-posix.h:44:20: error: unistd.h: No such file or
directory
In file included from ./gthr-default.h:1,
                 from ../.././gcc/gthr.h:114,
                 from ../.././gcc/unwind-dw2.c:42:
../.././gcc/gthr-posix.h:46: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘__gthread_key_t’
../.././gcc/gthr-posix.h:47: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘__gthread_once_t’
../.././gcc/gthr-posix.h:48: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘__gthread_mutex_t’
../.././gcc/gthr-posix.h:49: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘__gthread_recursive_mutex_t’
../.././gcc/gthr-posix.h:92: error: ‘pthread_once’ undeclared here (not
in a function)
../.././gcc/gthr-posix.h:92: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_once’
../.././gcc/gthr-posix.h:93: error: ‘pthread_getspecific’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:93: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_getspecific’
../.././gcc/gthr-posix.h:94: error: ‘pthread_setspecific’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:94: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_setspecific’
../.././gcc/gthr-posix.h:95: error: ‘pthread_create’ undeclared here
(not in a function)
../.././gcc/gthr-posix.h:95: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_create’
../.././gcc/gthr-posix.h:96: error: ‘pthread_cancel’ undeclared here
(not in a function)
../.././gcc/gthr-posix.h:96: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_cancel’
../.././gcc/gthr-posix.h:97: error: ‘pthread_mutex_lock’ undeclared here
(not in a function)
../.././gcc/gthr-posix.h:97: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutex_lock’
../.././gcc/gthr-posix.h:98: error: ‘pthread_mutex_trylock’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:98: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutex_trylock’
../.././gcc/gthr-posix.h:99: error: ‘pthread_mutex_unlock’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:99: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutex_unlock’
../.././gcc/gthr-posix.h:100: error: ‘pthread_mutex_init’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:100: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutex_init’
../.././gcc/gthr-posix.h:103: error: ‘pthread_key_create’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:103: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_key_create’
../.././gcc/gthr-posix.h:104: error: ‘pthread_key_delete’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:104: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_key_delete’
../.././gcc/gthr-posix.h:105: error: ‘pthread_mutexattr_init’ undeclared
here (not in a function)
../.././gcc/gthr-posix.h:105: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutexattr_init’
../.././gcc/gthr-posix.h:106: error: ‘pthread_mutexattr_settype’
undeclared here (not in a function)
../.././gcc/gthr-posix.h:106: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutexattr_settype’
../.././gcc/gthr-posix.h:107: error: ‘pthread_mutexattr_destroy’
undeclared here (not in a function)
../.././gcc/gthr-posix.h:107: warning: type defaults to ‘int’ in
declaration of ‘__gthrw_pthread_mutexattr_destroy’
../.././gcc/gthr-posix.h:572: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:581: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:587: error: expected ‘)’ before ‘key’
../.././gcc/gthr-posix.h:593: error: expected ‘)’ before ‘key’
../.././gcc/gthr-posix.h:599: error: expected ‘)’ before ‘key’
../.././gcc/gthr-posix.h:605: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:614: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:623: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:633: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:654: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:660: error: expected ‘)’ before ‘*’ token
../.././gcc/gthr-posix.h:666: error: expected ‘)’ before ‘*’ token
../.././gcc/unwind-dw2.c: In function ‘uw_init_context_1’:
../.././gcc/unwind-dw2.c:1417: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘once_regsizes’
../.././gcc/unwind-dw2.c:1417: error: ‘once_regsizes’ undeclared (first
use in this function)
../.././gcc/unwind-dw2.c:1417: error: (Each undeclared identifier is
reported only once
../.././gcc/unwind-dw2.c:1417: error: for each function it appears in.)
../.././gcc/unwind-dw2.c:1417: error: ‘PTHREAD_ONCE_INIT’ undeclared
(first use in this function)
../.././gcc/unwind-dw2.c:1418: warning: implicit declaration of function
‘__gthread_once’
make[2]: *** [libgcc/./unwind-dw2.o] Error 1
make[2]: Leaving directory
`/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory
`/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/gcc'
make: *** [all-gcc] Error 2


Thoughts?
FM



On Fri, 2008-02-15 at 11:30 -0700, Frank W. Miller wrote:
> OK, so I'm off trying to build the x86_64 cross toolchain.  My host is
> FC8 on a PC.
> 
> binutils-2.18 builds fine.
> 
> configure --target=x86_64-elf
> make
> make install
> 
> This gets me a nice set of tools in /usr/local/x86_64-elf/bin
> 
> I then try to build gcc-4.2.3
> 
> I tried:
> 
> configure --prefix=/usr/local --target=x86_64-elf
> make all-gcc
> 
> This gets me an error saying x86_64-elf is not a supported target.  I
> think tried substituting make all-gcc with make -k (after deleting the
> source tree and starting over).  I get this error somewhere down the
> line:
> 
> source='../.././libdecnumber/decimal128.c' object='decimal128.o'
> libtool=no gcc  -I../.././libdecnumber -I.  -g -O2 -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
> -Wno-long-long  -I../.././libdecnumber -I.
> -c ../.././libdecnumber/decimal128.c
> rm -f libdecnumber.a
> ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o
> decimal64.o decimal128.o
> ranlib libdecnumber.a
> make[2]: Leaving directory
> `/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/libdecnumber'
> make[1]: Target `all-host' not remade because of errors.
> make[1]: Target `all-target' not remade because of errors.
> make[1]: Leaving directory `/home/fwmiller/Desktop/gcc-4.2.3'
> make: *** [all] Error 2
> 
> 
> Can anyone comment?
> 
> Thanks,
> FM
> 
> 
> 

Re: Building cross compiler for x86_64

[Brian Dessent]

"Frank W. Miller" wrote:

> /home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/gcc/xgcc
> -B/home/fwmiller/Desktop/gcc-4.2.3/host-i686-pc-linux-gnu/gcc/
> -B/usr/local/x86_64-pc-linux/bin/ -B/usr/local/x86_64-pc-linux/lib/
> -isystem /usr/local/x86_64-pc-linux/include
> -isystem /usr/local/x86_64-pc-linux/sys-include -O2  -O2 -g -O2
> -DIN_GCC -DCROSS_COMPILE -DNATIVE_CROSS   -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
> -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc
> -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
> -I../.././gcc/../libdecnumber -I../libdecnumber -fexceptions
> -fvisibility=hidden -DHIDE_EXPORTS -c ../.././gcc/unwind-dw2.c -o
> libgcc/./unwind-dw2.o

This is the stage 3 compiler being used to build libgcc, and:

> ../.././gcc/gthr-posix.h:43:21: error: pthread.h: No such file or
> directory
> ../.././gcc/gthr-posix.h:44:20: error: unistd.h: No such file or
> directory

... like I said, you can't build libgcc without target libc headers.  I
don't know why the all-gcc rule still tries to build parts of libgcc. 
But you already have the bare compiler built at this point so for
freestanding work that should be enough.  You can try something like
"make -k install-gcc" and see what happens, or do it manually.

Brian

Re: Building cross compiler for x86_64

[NightStrike]

On Feb 16, 2008 9:51 PM, Brian Dessent <brian@dessent.net> wrote:
> ... like I said, you can't build libgcc without target libc headers.  I
> don't know why the all-gcc rule still tries to build parts of libgcc.

What parts does it try to build?

RE: Building cross compiler for x86_64

[Frank W. Miller]

I just need the C cross compiler and binutils, nothing else.

Thanks,
FM


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of NightStrike
Sent: Saturday, February 16, 2008 7:56 PM
To: gcc-help
Cc: Frank W. Miller
Subject: Re: Building cross compiler for x86_64

On Feb 16, 2008 9:51 PM, Brian Dessent <brian@dessent.net> wrote:
> ... like I said, you can't build libgcc without target libc headers.  I
> don't know why the all-gcc rule still tries to build parts of libgcc.

What parts does it try to build?