Re: egcs-ss-970821 - Run-Time Library Cross Problems

Re: egcs-ss-970821 - Run-Time Library Cross Problems

[Jim Wilson]

	When/where will gcc build its version of limits.h?

I haven't thought about this issue yet, though I have noticed that this
is about the third or fourth time that you have mentioned it.   It seems
pretty obvious by now that we need to do something about it, though
for the moment, I have plenty of more important problems to keep me busy.

Jim

Re: egcs-ss-970821 - Run-Time Library Cross Problems

[Joel Sherrill]

On Sat, 23 Aug 1997, Jim Wilson wrote:

> 	When/where will gcc build its version of limits.h?
> 
> I haven't thought about this issue yet, though I have noticed that this
> is about the third or fourth time that you have mentioned it.   It seems
> pretty obvious by now that we need to do something about it, though
> for the moment, I have plenty of more important problems to keep me busy.

It is really a very small problem but it is in the same class as the
run-time libraries.  I just want to make sure it doesn't slip through the
cracks.

--joel

Re: egcs-ss-970821 - Run-Time Library Cross Problems

[Joel Sherrill]

On Sat, 23 Aug 1997, Jim Wilson wrote:

> 	While compiling egcs-ss-970821 to target m68k-rtems, I had to disable
> 	Objective-C and g77 because both assume the existence of a target
> 	C library to build their runtimes.
> 
> Now (as of the next snapshot) that we have gcc and libstdc++ as toplevel
> directories, I would suggest moving the Objective-C runtime and the f77
> runtime out of the gcc directory and into toplevel directories of their own.

Great.  That would certainly fix one of the worst problems in building a
cross environment.  When/where will gcc build its version of limits.h?

> We can then have the toplevel Makefile build gcc first, and then the
> C++/Objective-C/F77 runtimes.  Anyone who needs to build a C library can
> then easily build it after gcc, and before the other language runtimes.

Marvelous!!! 

> This avoids the need for having multiple entry points in the gcc Makefile,
> something which would probably just make gcc unnecessarily complicated.

It is pretty complicated already. :)

--joel

Re: egcs-ss-970821 - Run-Time Library Cross Problems

[Jim Wilson]

	While compiling egcs-ss-970821 to target m68k-rtems, I had to disable
	Objective-C and g77 because both assume the existence of a target
	C library to build their runtimes.

Now (as of the next snapshot) that we have gcc and libstdc++ as toplevel
directories, I would suggest moving the Objective-C runtime and the f77
runtime out of the gcc directory and into toplevel directories of their own.

We can then have the toplevel Makefile build gcc first, and then the
C++/Objective-C/F77 runtimes.  Anyone who needs to build a C library can
then easily build it after gcc, and before the other language runtimes.

This avoids the need for having multiple entry points in the gcc Makefile,
something which would probably just make gcc unnecessarily complicated.

Jim

egcs-ss-970821 - Run-Time Library Cross Problems

[Joel Sherrill]

While compiling egcs-ss-970821 to target m68k-rtems, I had to disable
Objective-C and g77 because both assume the existence of a target
C library to build their runtimes.  As we add more and more language
front ends, the problems associated with target runtime files is getting
worse.  This seems to be increasing the pain of building a cross to an
embedded target.

THe objective-c runtime problem is well known.  The g77 error message was:

/usr1/rtems/work/build-m68k-tools/gcc/xgcc
-B/usr1/rtems/work/build-m68k-tools/gcc/ -c -g0 -o VersionI.o
/usr1/rtems/work/src/gcc/f/runtime/libI77/Version.c
/usr1/rtems/work/src/gcc/f/runtime/libI77/Version.c:265: stdio.h: No such
file or directory

For now, I have disabled both objective-c and fortran in my build tree.
I would like to include them though. :(

This does point out a benefit of including as many of the language
frontends as possible in egcs.  I am reporting problems with a cross
embedded configuration of g77. I certainly would never have turned up this
problem if it had not been in the tree. :)

--joel