Toolchain build is broken

pedward · 2012-06-13 00:18

propeller-elf-gcc -Wall -Werror -m64bit-doubles -Os -nostdinc -I./include -r -mcog -Wl,--defsym,__i2c_driver=1 -o ../../build/lib/obj/lmm/i2c_driver.cog sys/propeller/i2c_driver.c
/opt/parallax/lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: cannot find spinboot.o: No such file or directory
/opt/parallax/lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: cannot find crt0_cog.o: No such file or directory
/opt/parallax/lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: cannot find -lgcc
/opt/parallax/lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: cannot find -lcog
/opt/parallax/lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: cannot find -lgcc
/opt/parallax/lib/gcc/propeller-elf/4.6.1/../../../../propeller-elf/bin/ld: cannot find crtend_cog.o: No such file or directory
collect2: ld returned 1 exit status
make[1]: *** [../../build/lib/obj/lmm/i2c_driver.cog] Error 1
make[1]: Leaving directory `/home/pedward/workspace/propgcc/propgcc/lib'
make: *** [all] Error 2
library build failed - make

I get this on a virgin clone of the repo.

Build env is Fedora 15, Core i5-2310
Linux pooh.apsoft.com 2.6.42.3-2.fc15.x86_64 #1 SMP Thu Feb 9 01:42:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

David Betz · 2012-06-13 03:53

I found the same problem trying to build under both Fedora 17 and Ubuntu 12.04. I think something must have changed in the x86 gcc tool chain recently.

jazzed · 2012-06-13 08:26

I'm looking into this. Don't have anything better to do LOL.

David Betz · 2012-06-13 08:31

jazzed wrote: »

I'm looking into this. Don't have anything better to do LOL.

What I found is that the c++ library build that is part of build/gcc was failing but the main rebuild.sh and jbuild.sh scripts weren't noticing that and continuing. This caused any builds using propeller-elf-gcc to fail because their support files were never installed. So, I think there are two problems.

1) the build/gcc build fails apparently due to some change in the way configuration scripts work
2) the jbuild.sh script doesn't notice that the build fails and proceeds to other things that later fail when they need the results of the gcc support code builds

jazzed · 2012-06-13 09:58

I haven't had any build troubles with fedora-16 (x86_64), debian-6.0.2 (i686 or x86_64), mac-osx Lion, or windows. We will go to beta with binary distributions.

I installed fedora-17 (x86_64) VM and get a gcc script build failure. This needs to be fixed, there is a patch for this part which we can probably push to our repository. Will look at this.

gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../../propgcc/gcc/gcc -I../../../propgcc/gcc/gcc/. -I../../../propgcc/gcc/gcc/../include -I../../../propgcc/gcc/gcc/../libcpp/include -I/home/steve/gcc/build/gcc/./gmp -I/home/steve/gcc/propgcc/gcc/gmp -I/home/steve/gcc/build/gcc/./mpfr -I/home/steve/gcc/propgcc/gcc/mpfr -I/home/steve/gcc/propgcc/gcc/mpc/src  -I../../../propgcc/gcc/gcc/../libdecnumber -I../../../propgcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber    ../../../propgcc/gcc/gcc/haifa-sched.c -o haifa-sched.o
gtype-desc.c:8946:18: error: subscripted value is neither array nor pointer nor vector
gtype-desc.c:9065:36: error: subscripted value is neither array nor pointer nor vector
gtype-desc.c:9149:31: error: subscripted value is neither array nor pointer nor vector
gtype-desc.c:9170:31: error: subscripted value is neither array nor pointer nor vector
gtype-desc.c:9177:31: error: subscripted value is neither array nor pointer nor vector
gtype-desc.c:9184:31: error: subscripted value is neither array nor pointer nor vector
gcc -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../../propgcc/gcc/gcc -I../../../propgcc/gcc/gcc/. -I../../../propgcc/gcc/gcc/../include -I../../../propgcc/gcc/gcc/../libcpp/include -I/home/steve/gcc/build/gcc/./gmp -I/home/steve/gcc/propgcc/gcc/gmp -I/home/steve/gcc/build/gcc/./mpfr -I/home/steve/gcc/propgcc/gcc/mpfr -I/home/steve/gcc/propgcc/gcc/mpc/src  -I../../../propgcc/gcc/gcc/../libdecnumber -I../../../propgcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber    ../../../propgcc/gcc/gcc/hooks.c -o hooks.o
make[1]: *** [gtype-desc.o] Error 1
make[1]: *** Waiting for unfinished jobs....
rm cpp.pod fsf-funding.pod gcc.pod gcov.pod gfdl.pod
make[1]: Leaving directory `/home/steve/gcc/build/gcc/gcc'
make: *** [all-gcc] Error 2
gcc make all-gcc failed.
[steve@localhost propgcc]$

I don't see any other build errors that would account for the OP problem. David, please point them out for me.

As for the OP issue, I've removed building the i2c stuff and everything builds no problems. The thing is without that library support, certain features that we added will not work - that would be using "eCOG" loading. The eCOG loader library builds fine the default build virtual machines for distributions that I've tried so far.

Below are diffs to get a build working. The second one should be considered optional at this point. If you apply it, the propgcc/demos/cog_loader and other programs using eCOG will not work.

[steve@localhost propgcc]$ hg diff
diff -r af23f66093d8 gcc/gcc/gengtype.c
--- a/gcc/gcc/gengtype.c    Tue Jun 12 17:09:21 2012 -0300
+++ b/gcc/gcc/gengtype.c    Wed Jun 13 09:53:41 2012 -0700
@@ -3598,9 +3598,11 @@
      subcomponent of V, we can mark any subarrays with a single stride.
      We're effectively treating the field as a global variable in its
      own right.  */
+
+  struct pair newv; // moved out of if because of scope problem
+
   if (v && type == v->type)
     {
-      struct pair newv;
 
       newv = *v;
       newv.type = field_type;
diff -r af23f66093d8 lib/Makefile.incl
--- a/lib/Makefile.incl    Tue Jun 12 17:09:21 2012 -0300
+++ b/lib/Makefile.incl    Wed Jun 13 09:53:41 2012 -0700
@@ -93,9 +93,10 @@
 DRIVERS = SimpleSerial.o serialparam.o serial_break.o serial_exit.o memory.o \
     FdSerial.o FullDuplexSerial.o null.o drivers.o rtc.o terminal.o \
     FileDriver.o mount.o dosfs.o file_io.o load_sd_driver.o sd_driver.o \
-    rtc_cog.o i2c_simple.o \
-    i2c_interface.o i2c_common.o i2c_driver.cog i2c_driver_boot.cog \
+    rtc_cog.o \
     boot_read.o boot_write.o
+
+    #i2c_simple.o i2c_interface.o i2c_common.o i2c_driver.cog i2c_driver_boot.cog \
     
 LIBM =     k_rem_pio2.o k_cos.o k_sin.o k_tan.o \
     k_rem_pio2f.o k_cosf.o k_sinf.o k_tanf.o \
[steve@localhost propgcc]$

We are looking into what it takes to make all this work the way it should so source builder folks can also use eCOG.

We will probably go to beta with binary distributions that will be feature complete.

Thanks,
--Steve

David Betz · 2012-06-13 11:09

You can't remove the i2c stuff to fix this problem. I don't think any propeller programs will build with this configure script issue because the support code isn't getting built. At the least, it will prevent an -mcog programs from being built but my guess is that the other crt0 variants are also going to have problems.

pedward · 2012-06-13 12:01

Point of note:

find . -name 'crt0_cog.*'
./gcc/gcc/config/propeller/crt0_cog.s
./lib/cog/crt0_cog.s

So, the support files are not being build prior to actually building this.

David Betz · 2012-06-13 12:25

pedward wrote: »

Point of note:

So, the support files are not being build prior to actually building this.

I think we have this figured out. I'm going to update jbuild.sh later tonight to fix this problem. Sorry for the trouble it has caused!!

pedward · 2012-06-13 23:04

I applied Steve's patch (although tonight's code was different) and got the toolchain to build.

David Betz · 2012-06-14 12:23

Eric has fixed the toolchain build. It turns out that it didn't have anything to do with which Linux distro you were using. It had more to do with whether you still had an old copy of propgcc on your system. There was a problem in the order in which things were built that caused a failure on builds where /opt/parallax was empty at the start of the build. Eric fixed this and has pushed his changes. I've been able to successfully build from scratch on Mac OS X and Ubuntu 12.04. I imagine Steve will try Fedora 17 when he gets back from lunch.

Thanks Eric!!!!

Martin Hodge · 2012-06-14 16:58

Rev: 2eb4b6075c80 on Fedora 17: I'm still getting the build error Steve found.

David Betz · 2012-06-14 17:41

Martin Hodge wrote: »

Rev: 2eb4b6075c80 on Fedora 17: I'm still getting the build error Steve found.

I guess Steve hasn't checked in the fix for that. You can find it online with a google search. I fixed it when I had Fedora 17 installed but I've moved over to Ubuntu 12.04 now and it doesn't seem to have this problem. I think the problem is due to the fact that Fedora 17 is now using GCC 4.7.

jazzed · 2012-06-14 19:02

Just pushed the change Martin. Sorry it took so long. Also pushed a loader change that fixes an issue i had with my Fedora-17 VM.

Toolchain build is broken

Comments