* one tree builds
@ 1997-11-24 18:07 Joel Sherrill
1997-11-25 19:10 ` Jeffrey A Law
0 siblings, 1 reply; 12+ messages in thread
From: Joel Sherrill @ 1997-11-24 18:07 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-24 18:07 one tree builds Joel Sherrill
@ 1997-11-25 19:10 ` Jeffrey A Law
1997-11-25 19:56 ` Joel Sherrill
0 siblings, 1 reply; 12+ messages in thread
From: Jeffrey A Law @ 1997-11-25 19:10 UTC (permalink / raw)
To: Joel Sherrill; +Cc: egcs
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-25 19:56 ` Joel Sherrill
@ 1997-11-25 19:56 ` Jeffrey A Law
1997-11-25 20:17 ` Joel Sherrill
0 siblings, 1 reply; 12+ messages in thread
From: Jeffrey A Law @ 1997-11-25 19:56 UTC (permalink / raw)
To: Joel Sherrill; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-25 19:10 ` Jeffrey A Law
@ 1997-11-25 19:56 ` Joel Sherrill
1997-11-25 19:56 ` Jeffrey A Law
0 siblings, 1 reply; 12+ messages in thread
From: Joel Sherrill @ 1997-11-25 19:56 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-25 19:56 ` Jeffrey A Law
@ 1997-11-25 20:17 ` Joel Sherrill
1997-11-26 22:57 ` Jeffrey A Law
0 siblings, 1 reply; 12+ messages in thread
From: Joel Sherrill @ 1997-11-25 20:17 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-25 20:17 ` Joel Sherrill
@ 1997-11-26 22:57 ` Jeffrey A Law
1997-11-27 5:50 ` Joel Sherrill
1997-11-27 19:11 ` Chris Johns
0 siblings, 2 replies; 12+ messages in thread
From: Jeffrey A Law @ 1997-11-26 22:57 UTC (permalink / raw)
To: Joel Sherrill; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-26 22:57 ` Jeffrey A Law
@ 1997-11-27 5:50 ` Joel Sherrill
1997-11-27 19:11 ` Chris Johns
1 sibling, 0 replies; 12+ messages in thread
From: Joel Sherrill @ 1997-11-27 5:50 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-26 22:57 ` Jeffrey A Law
1997-11-27 5:50 ` Joel Sherrill
@ 1997-11-27 19:11 ` Chris Johns
1997-11-28 1:30 ` Mumit Khan
1997-11-29 10:38 ` Joel Sherrill
1 sibling, 2 replies; 12+ messages in thread
From: Chris Johns @ 1997-11-27 19:11 UTC (permalink / raw)
To: law; +Cc: Joel Sherrill, egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-27 19:11 ` Chris Johns
@ 1997-11-28 1:30 ` Mumit Khan
1998-01-13 4:52 ` Jeffrey A Law
1997-11-29 10:38 ` Joel Sherrill
1 sibling, 1 reply; 12+ messages in thread
From: Mumit Khan @ 1997-11-28 1:30 UTC (permalink / raw)
To: Chris Johns; +Cc: egcs
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. */
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-27 19:11 ` Chris Johns
1997-11-28 1:30 ` Mumit Khan
@ 1997-11-29 10:38 ` Joel Sherrill
1 sibling, 0 replies; 12+ messages in thread
From: Joel Sherrill @ 1997-11-29 10:38 UTC (permalink / raw)
To: Chris Johns; +Cc: law, egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1997-11-28 1:30 ` Mumit Khan
@ 1998-01-13 4:52 ` Jeffrey A Law
1998-01-13 8:04 ` Chris Johns
0 siblings, 1 reply; 12+ messages in thread
From: Jeffrey A Law @ 1998-01-13 4:52 UTC (permalink / raw)
To: Mumit Khan; +Cc: Chris Johns, egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: one tree builds
1998-01-13 4:52 ` Jeffrey A Law
@ 1998-01-13 8:04 ` Chris Johns
0 siblings, 0 replies; 12+ messages in thread
From: Chris Johns @ 1998-01-13 8:04 UTC (permalink / raw)
To: law; +Cc: Mumit Khan, egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1998-01-13 8:04 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-11-24 18:07 one tree builds Joel Sherrill
1997-11-25 19:10 ` Jeffrey A Law
1997-11-25 19:56 ` Joel Sherrill
1997-11-25 19:56 ` Jeffrey A Law
1997-11-25 20:17 ` Joel Sherrill
1997-11-26 22:57 ` Jeffrey A Law
1997-11-27 5:50 ` Joel Sherrill
1997-11-27 19:11 ` Chris Johns
1997-11-28 1:30 ` Mumit Khan
1998-01-13 4:52 ` Jeffrey A Law
1998-01-13 8:04 ` Chris Johns
1997-11-29 10:38 ` Joel Sherrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).