one tree builds

one tree builds

[Joel Sherrill]

Hi,

I am in the process of trying to test 971122 and finding that this
snapshot has broken something in the one tree build procedure since the
970901 snapshot I last grabbed and successfully built.  The problem
appears to be that when libgcc1 is built, the cross gas is not found by
xgcc.  This happened on both sparc-rtems and m68k-rtems targets so I think
it is  a general build issue.  Here is the error message form the m68k
build:

cp ../../src/gcc/config/m68k/lb1sf68.asm libgcc1.S
for name in _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _double _float
_floatex _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 _eqsf2 _nesf2 _gtsf2
_gesf2 _ltsf2 _lesf2; \
do \
  echo ${name}; \
  /usr1/rtems/work/tools/build-m68k-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-m68k-tools/gcc/ -O2  -DCROSS_COMPILE
-DIN_GCC    -O2 -g -I./include   -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-fexceptions -Dinhibit_libc  -I. -I../../src/gcc -I../../src/gcc/config -c
-DL${name} libgcc1.S; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mv libgcc1.o ${name}.o; \
  /usr1/rtems/work/tools/build-m68k-tools/binutils/ar rc tmplibgcc1.a
${name}.o; \
  rm -f ${name}.o; \
done
_mulsi3
as: unrecognized option `-c68020'

I realize that the one-tree shell script from gcc 2.7.x will not work
since the gcc reorganization.  I am using a script which ends up doing
this:

rm -rf src
mkdir src
cd src

# EGCS has the latest configure scripts
for f in ../${GCC}/*
do
        ln -s $f .
done

for f in bfd binutils gas gprof ld opcodes
do
        ln -s ../${BINUTILS}/$f .
done

ln -s ../${NEWLIB}/newlib .

Does anyone have any ideas?  I was trying to make a test sweep through all
the rtems configurations before the egcs release.

Thanks.

--joel

Re: one tree builds

[Jeffrey A Law]

 
  > done
  > _mulsi3
  > as: unrecognized option `-c68020'
  > 
  > I realize that the one-tree shell script from gcc 2.7.x will not work
  > since the gcc reorganization.  I am using a script which ends up doing
  > this:
This would make me wonder if you're picking up the right assembler --
is the "as" link in the gcc dir pointing to the right place (keeping in
mind the as.new -> as-new transition a little while back).

jeff

Re: one tree builds

[Jeffrey A Law]

  In message < Pine.BSF.3.96.971125214303.4794B-100000@vespucci.advicom.net >you 
write:
  > > This would make me wonder if you're picking up the right assembler --
  > > is the "as" link in the gcc dir pointing to the right place (keeping in
  > > mind the as.new -> as-new transition a little while back).
  > 
  > I am sure I am not picking up the right assembler.  
  > 
  > My binutils is 2.8.1 and it is creating as.new while egcs is looking for
  > as-new.  It looks like the same problem applies to at least ld and nm as
  > well.
Yup, it applies to ld & nm too.

  > Is this something that has changed in binutils since the 2.8.1 release and
  > I need to change my binutils to create XYZ-new?
Yes.  Or change gcc to look for XYZ.new

I think this deserves a mention in the FAQ :-)
jeff

Re: one tree builds

[Joel Sherrill]

On Tue, 25 Nov 1997, Jeffrey A Law wrote:

>  
>   > _mulsi3
>   > as: unrecognized option `-c68020'
>   > 
>   > I realize that the one-tree shell script from gcc 2.7.x will not work
>   > since the gcc reorganization.  I am using a script which ends up doing
>   > this:
> This would make me wonder if you're picking up the right assembler --
> is the "as" link in the gcc dir pointing to the right place (keeping in
> mind the as.new -> as-new transition a little while back).

I am sure I am not picking up the right assembler.  

My binutils is 2.8.1 and it is creating as.new while egcs is looking for
as-new.  It looks like the same problem applies to at least ld and nm as
well.

Is this something that has changed in binutils since the 2.8.1 release and
I need to change my binutils to create XYZ-new?

--joel

Re: one tree builds

[Joel Sherrill]

On Tue, 25 Nov 1997, Jeffrey A Law wrote:

>   In message < Pine.BSF.3.96.971125214303.4794B-100000@vespucci.advicom.net >you 
> write:
>   > > This would make me wonder if you're picking up the right assembler --
>   > > is the "as" link in the gcc dir pointing to the right place (keeping in
>   > > mind the as.new -> as-new transition a little while back).
>   > 
>   > I am sure I am not picking up the right assembler.  
>   > 
>   > My binutils is 2.8.1 and it is creating as.new while egcs is looking for
>   > as-new.  It looks like the same problem applies to at least ld and nm as
>   > well.
> Yup, it applies to ld & nm to

I will fix it in my copy of binutiols in the morning and see how much
father I can get. :)
> 
>   > Is this something that has changed in binutils since the 2.8.1 release and
>   > I need to change my binutils to create XYZ-new?
> Yes.  Or change gcc to look for XYZ.new
> 
> I think this deserves a mention in the FAQ :-)

And possibly a synchronized binutils/crossgcc release as well.

What does the --enable-newlib option do?  Should I be using it on the
rtems configurations?

--joel

Re: one tree builds

[Jeffrey A Law]

  In message < Pine.BSF.3.96.971125220325.4794C-100000@vespucci.advicom.net >you 
write:
  > > Yes.  Or change gcc to look for XYZ.new
  > > 
  > > I think this deserves a mention in the FAQ :-)
  > 
  > And possibly a synchronized binutils/crossgcc release as well.
Well, I've put it in the egcs FAQ.  I'm not sure who maintains the
crossgcc faq (I believe Doug resigned as maintainer a short while ago).

  > What does the --enable-newlib option do?  Should I be using it on the
  > rtems configurations?
I don't think it does anything in egcs at the moment.  In Cygnus's gcc
tree it disables __eprintf in libgcc2, which has some marginal benefit
for cross builds.

jeff

Re: one tree builds

[Joel Sherrill]

On Wed, 26 Nov 1997, Jeffrey A Law wrote:

> Well, I've put it in the egcs FAQ.  I'm not sure who maintains the
> crossgcc faq (I believe Doug resigned as maintainer a short while ago).

Doug did a great job for crossgcc.  I know I really appreciated the effort
he put in.

>   > What does the --enable-newlib option do?  Should I be using it on the
>   > rtems configurations?
> I don't think it does anything in egcs at the moment.  In Cygnus's gcc
> tree it disables __eprintf in libgcc2, which has some marginal benefit
> for cross builds.

So it just turns on the -Dinhibit_libc flag for LIBGCC2_CFLAGS. :)

--joel

Re: one tree builds

[Chris Johns]

Jeffrey A Law wrote:
> 
>   In message < Pine.BSF.3.96.971125220325.4794C-100000@vespucci.advicom.net >you
> write:
>   > > Yes.  Or change gcc to look for XYZ.new
>   > >
>   > > I think this deserves a mention in the FAQ :-)
>   >
>   > And possibly a synchronized binutils/crossgcc release as well.
> Well, I've put it in the egcs FAQ.  I'm not sure who maintains the
> crossgcc faq (I believe Doug resigned as maintainer a short while ago).
> 
>   > What does the --enable-newlib option do?  Should I be using it on the
>   > rtems configurations?
> I don't think it does anything in egcs at the moment.  In Cygnus's gcc
> tree it disables __eprintf in libgcc2, which has some marginal benefit
> for cross builds.
> 

Without --enable-newlib I cannot get past libgcc2's __eprintf looking
for stdio.h when building a m68k-coff-gcc on a Linux machine.

With --enable-newlib I get to :

make[2]: Entering directory
`/ods/src/egcs/m68k-coff-gcc/m68k-coff/libiberty'
test -z "" || \
  /ods/src/egcs/m68k-coff-gcc/gcc/xgcc
-B/ods/src/egcs/m68k-coff-gcc/gcc/ -c -g -O2 -I.
-I../../../egcs-971122/libiberty/../include  
../../../egcs-971122/libiberty/choose-temp.c -o pic/choose-temp.o
/ods/src/egcs/m68k-coff-gcc/gcc/xgcc
-B/ods/src/egcs/m68k-coff-gcc/gcc/ -c -g -O2 -I.
-I../../../egcs-971122/libiberty/../include 
../../../egcs-971122/libiberty/choose-temp.c
../../../egcs-971122/libiberty/choose-temp.c:26: sys/types.h: No such
file or directory
../../../egcs-971122/libiberty/choose-temp.c:27: sys/file.h: No such
file or directory
../../../egcs-971122/libiberty/choose-temp.c:36: stdio.h: No such file
or directory
make[2]: *** [choose-temp.o] Error 1
make[2]: Leaving directory
`/ods/src/egcs/m68k-coff-gcc/m68k-coff/libiberty'
make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory `/ods/src/egcs/m68k-coff-gcc'
make: *** [cross] Error 2

The cross target make no difference here. I am not sure what has gone
wrong here.


-- 
 Chris Johns  Networks, Plessey Asia Pacfic Pty. Ltd.
  mailto:ccj@acm.org    mailto:cjohns@plessey.com.au

Re: one tree builds

[Mumit Khan]

Chris Johns <cjohns@plessey.com.au> writes:
> -I../../../egcs-971122/libiberty/../include 
> ../../../egcs-971122/libiberty/choose-temp.c
> ../../../egcs-971122/libiberty/choose-temp.c:26: sys/types.h: No such
> file or directory
> ../../../egcs-971122/libiberty/choose-temp.c:27: sys/file.h: No such
> file or directory
> ../../../egcs-971122/libiberty/choose-temp.c:36: stdio.h: No such file
> or directory

choose-temp in both gcc and libiberty need a tiny fix so that config
file for the host can define NO_SYS_FILE_H. As for stdio.h,
--enable-newlib should've supplied the include path to it.

Thu Nov  6 11:23:49 1997  Mumit Khan  <khan@xraylith.wisc.edu>

	* choose-temp.c: Change order of includes so that config.h can
	define NO_SYS_FILE_H. Needed when used in gcc, but not libiberty.


Index: mingw32/gcc/choose-temp.c
diff -u mingw32/gcc/choose-temp.c:1.1.1.1 mingw32/gcc/choose-temp.c:1.2
--- mingw32/gcc/choose-temp.c:1.1.1.1	Sun Nov  2 15:31:41 1997
+++ mingw32/gcc/choose-temp.c	Thu Nov  6 18:49:55 1997
@@ -22,17 +22,6 @@
 /* This file lives in at least two places: libiberty and gcc.
    Don't change one without the other.  */
 
-#ifndef NO_SYS_FILE_H
-#include <sys/types.h>
-#include <sys/file.h>   /* May get R_OK, etc. on some systems.  */
-#endif
-
-#ifndef R_OK
-#define R_OK 4
-#define W_OK 2
-#define X_OK 1
-#endif
-
 #include <stdio.h>	/* May get P_tmpdir.  */
 
 #ifdef IN_GCC
@@ -50,6 +39,18 @@
 #ifndef DIR_SEPARATOR
 #define DIR_SEPARATOR '/'
 #endif
+
+#ifndef NO_SYS_FILE_H
+#include <sys/types.h>
+#include <sys/file.h>   /* May get R_OK, etc. on some systems.  */
+#endif
+
+#ifndef R_OK
+#define R_OK 4
+#define W_OK 2
+#define X_OK 1
+#endif
+
 
 /* On MSDOS, write temp files in current dir
    because there's no place else we can expect to use.  */

Re: one tree builds

[Joel Sherrill]

On Fri, 28 Nov 1997, Chris Johns wrote:

> 
> Without --enable-newlib I cannot get past libgcc2's __eprintf looking
> for stdio.h when building a m68k-coff-gcc on a Linux machine.

Hmmm.. I did not know this option existed so for the RTEMS targets I have
not even used it.  m68k-rtems is essentially m68k-coff so I do not
understand wht the problem could be.

> With --enable-newlib I get to :
> 
> make[2]: Entering directory
> `/ods/src/egcs/m68k-coff-gcc/m68k-coff/libiberty'
> test -z "" || \
>   /ods/src/egcs/m68k-coff-gcc/gcc/xgcc
> -B/ods/src/egcs/m68k-coff-gcc/gcc/ -c -g -O2 -I.
> -I../../../egcs-971122/libiberty/../include  
> ../../../egcs-971122/libiberty/choose-temp.c -o pic/choose-temp.o
> /ods/src/egcs/m68k-coff-gcc/gcc/xgcc
> -B/ods/src/egcs/m68k-coff-gcc/gcc/ -c -g -O2 -I.
> -I../../../egcs-971122/libiberty/../include 
> ../../../egcs-971122/libiberty/choose-temp.c
> ../../../egcs-971122/libiberty/choose-temp.c:26: sys/types.h: No such
> file or directory
> ../../../egcs-971122/libiberty/choose-temp.c:27: sys/file.h: No such
> file or directory
> ../../../egcs-971122/libiberty/choose-temp.c:36: stdio.h: No such file
> or directory
> make[2]: *** [choose-temp.o] Error 1
> make[2]: Leaving directory
> `/ods/src/egcs/m68k-coff-gcc/m68k-coff/libiberty'
> make[1]: *** [all-target-libiberty] Error 2
> make[1]: Leaving directory `/ods/src/egcs/m68k-coff-gcc'
> make: *** [cross] Error 2
> 
> The cross target make no difference here. I am not sure what has gone
> wrong here.


-joel

Re: one tree builds

[Jeffrey A Law]

  In message <9711280724.AA15492@modi.xraylith.wisc.edu>you write:
  > Chris Johns <cjohns@plessey.com.au> writes:
  > > -I../../../egcs-971122/libiberty/../include 
  > > ../../../egcs-971122/libiberty/choose-temp.c
  > > ../../../egcs-971122/libiberty/choose-temp.c:26: sys/types.h: No such
  > > file or directory
  > > ../../../egcs-971122/libiberty/choose-temp.c:27: sys/file.h: No such
  > > file or directory
  > > ../../../egcs-971122/libiberty/choose-temp.c:36: stdio.h: No such file
  > > or directory
  > 
  > choose-temp in both gcc and libiberty need a tiny fix so that config
  > file for the host can define NO_SYS_FILE_H. As for stdio.h,
  > --enable-newlib should've supplied the include path to it.
  > 
  > Thu Nov  6 11:23:49 1997  Mumit Khan  <khan@xraylith.wisc.edu>
  > 
  > 	* choose-temp.c: Change order of includes so that config.h can
  > 	define NO_SYS_FILE_H. Needed when used in gcc, but not libiberty.
I don't see why this patch is needed.

config.h is included before the NO_SYS_FILE_H check, so doesn't that
give us the override capability we need?

Based on the error message I suspect Chris didn't have any target include
files for the compimler to use -- note that it couldn't find stdio.h!


jeff

Re: one tree builds

[Chris Johns]

Jeffrey A Law wrote:
> 
>   In message <9711280724.AA15492@modi.xraylith.wisc.edu>you write:
>   > Chris Johns <cjohns@plessey.com.au> writes:
>   > > -I../../../egcs-971122/libiberty/../include
>   > > ../../../egcs-971122/libiberty/choose-temp.c
>   > > ../../../egcs-971122/libiberty/choose-temp.c:26: sys/types.h: No such
>   > > file or directory
>   > > ../../../egcs-971122/libiberty/choose-temp.c:27: sys/file.h: No such
>   > > file or directory
>   > > ../../../egcs-971122/libiberty/choose-temp.c:36: stdio.h: No such file
>   > > or directory
>   >
>   > choose-temp in both gcc and libiberty need a tiny fix so that config
>   > file for the host can define NO_SYS_FILE_H. As for stdio.h,
>   > --enable-newlib should've supplied the include path to it.
>   >
>   > Thu Nov  6 11:23:49 1997  Mumit Khan  <khan@xraylith.wisc.edu>
>   >
>   >     * choose-temp.c: Change order of includes so that config.h can
>   >     define NO_SYS_FILE_H. Needed when used in gcc, but not libiberty.
> I don't see why this patch is needed.
> 
> config.h is included before the NO_SYS_FILE_H check, so doesn't that
> give us the override capability we need?
> 
> Based on the error message I suspect Chris didn't have any target include
> files for the compimler to use -- note that it couldn't find stdio.h!
> 

Yeap that was what happen. I have a working egcs cross compiler.

-- 
 Chris Johns  Networks, Plessey Asia Pacfic Pty. Ltd.
  mailto:ccj@acm.org    mailto:cjohns@plessey.com.au