I'm at a bit of a loss. The first time I tried to run INSTALL.py it failed at about 78%, but gave no error message. I went in to the bin directory and did "make", and it ran fine.
I've actually been trying to fix this anomaly for a long time. It has to do with running multi-threaded make - I don't have the dependencies set correctly so sometimes it builds in the wrong order and fails. I probably shouldn't be using "-j" in INSTALL.py but it just takes forever if I omit it.
Spinsim is failing with linker issues. I'm on my phone so I can't copy/paste very easily, but its there in the build log (win gcc4 is what I looked at)
Spinsim is failing with linker issues. I'm on my phone so I can't copy/paste very easily, but its there in the build log (win gcc4 is what I looked at)
At least propeller-load built okay this time! I sent email to Dave Hein to see if he knew why restore_console_io() would be undefined for a Windows build.
I just checked and it looks like initialize_console_io() and restore_console_io() were added since the version of spinsim that is included in the propgcc project and they seem not to be defined for Windows builds.
Finally got a successful Windows build! Unfortunately, I did that by commenting out the calls to initialize_console_io() and restore_console_io(). Those functions were defined as NOPs for Linux and Mac builds and were totally undefined for Windows builds. I've sent Dave Hein email asking him about the correct resolution of this problem. In any case, Windows builds are now working.
NOTE: I do not mean for this to be "pushy" or impatient in any way. Purely practical.
If it will be a while before the new propeller-gcc repository is ready for prime time, would it be helpful if I put https://github.com/parallaxinc/propgcc into TeamCity? It would require a bit of extra work and space on the server, but I'm okay with that if it would prove useful.
NOTE: I do not mean for this to be "pushy" or impatient in any way. Purely practical.
If it will be a while before the new propeller-gcc repository is ready for prime time, would it be helpful if I put https://github.com/parallaxinc/propgcc into TeamCity? It would require a bit of extra work and space on the server, but I'm okay with that if it would prove useful.
Yes, it would probably be useful until propeller-gcc is proven and ready. Thanks for offering!
Hmmm... I was able to reproduce the seeedtftfast_as.S crash using the win32 cross build. I will try to debug it. I'm not sure why I didn't get it on my linux build; stale files perhaps.
Anyway, just wanted to let you know that it hasn't been forgotten.
Does gdbstub need to be modified for the new gdb or should it work as-is? I'll try to get it moved over this weekend.
The protocol hasn't changed, and it seemed to work for me, so it *should* work as-is. It's always possible that I messed something up in the port, though!
I also enabled the propeller-elf-gdb build in the new binutils. We still need to move gdbstub over.
I'm afraid that killed the Raspberry Pi build
[06:32:02][Step 3/5] checking for library containing tgetent... no
[06:32:02][Step 3/5] configure: error: no termcap library found
Google told me that I needed to install ncurse-dev, but when I tried, I got this:
dzweb@davidzemonname:~$ sudo apt-get install ncurses-
ncurses-base ncurses-doc ncurses-hexedit
ncurses-bin ncurses-examples ncurses-term
dzweb@davidzemonname:~$ sudo apt-get install ncurses-dev
[sudo] password for dzweb:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libncurses5-dev' instead of 'ncurses-dev'
libncurses5-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
dzweb@davidzemonname:~$
The first command is me trying to use tab-complete to find ncurses-dev... which isn't there (the Google link I found was using yum, so I guess that was redhat right, not Ubuntu?). But then apt I try it anyway and apt is smart enough to do the right thing... but it was already done.
So my best guess is that the arm cross compiler needs its own version of the terncap library, and that isn't included in the package downloaded via the instructions on the wiki
So my best guess is that the arm cross compiler needs its own version of the terncap library, and that isn't included in the package downloaded via the instructions on the wiki
Yes. You'll need to build ncurses for the ARM (or find a precompiled binary compatible with the raspberry pi). This has bitten us before :-(. There's a git repo for ncurses at:
git://ncurses.scripts.mit.edu/ncurses.git
It's been a while since I built it, but I seem to recall that it was pretty straightforward to build for the pi. Alternatively, you could move the files from your rasbian install over to your x86 build machine.
Yes. You'll need to build ncurses for the ARM (or find a precompiled binary compatible with the raspberry pi). This has bitten us before :-(. There's a git repo for ncurses at:
git://ncurses.scripts.mit.edu/ncurses.git
It's been a while since I built it, but I seem to recall that it was pretty straightforward to build for the pi. Alternatively, you could move the files from your rasbian install over to your x86 build machine.
ncurses sources were checked into the propgcc project and there is code to build it at the top of the Makefile. That code is also in the propeller-gcc Makefile but the ncurses directory itself is missing. Maybe I should add the URL you mention as a submodule of propeller-gcc and reinstate the Makefile dependency on the ncurses build when the target is the RaspberryPi?
Here is another warning I got compiling gdb. It looks to me as though the ones complaining about the length being a comparison are actually bugs in gdb.
gcc -Wno-string-plus-int -Wno-deprecated-declarations -Wno-empty-body -Wno-self-assign -Wno-sometimes-uninitialized -Wno-uninitialized -Wno-unknown-warning-option -I. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/common -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/config -DLOCALEDIR="\"/Users/dbetz/parallax/propeller-gcc4-build/target/share/locale\"" -DHAVE_CONFIG_H -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include/opcode -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../opcodes/.. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../readline/.. -I../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include -I../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -Werror -c -o remote.o -MT remote.o -MMD -MP -MF .deps/remote.Tpo /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c
/Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:5536:47: error: size argument in 'strncmp' call is a comparison
[-Werror,-Wmemsize-comparison]
&& strncmp (p, "core", strlen ("core") != 0))
~~~~~~~~~~~~~~~~^~~~
/Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:5536:11: note: did you mean to compare the result of 'strncmp' instead?
&& strncmp (p, "core", strlen ("core") != 0))
^ ~
)
/Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:5536:31: note: explicitly cast the argument to size_t to silence this
warning
&& strncmp (p, "core", strlen ("core") != 0))
^
(size_t)( )
/Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:7003:37: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
if (vsnprintf (rs->buf, max_size, format, ap) >= max_size)
^~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/secure/_stdio.h:75:63: note:
expanded from macro 'vsnprintf'
__builtin___vsnprintf_chk (str, len, 0, __darwin_obsz(str), format, ap)
^
2 errors generated.
I fixed the gdb bug mentioned in message #202 above but I'm still getting the warning about a non-constant printf format string. The problem is, I can't fix it by my normal method of adding it to fix-xcode-warnings.sh because it looks like the gdb Makefile explicitly sets -Wformat-nonliteral which overrides my CFLAGS environment variable. Any idea how to fix this?
I'm afraid I'm stuck. I started working on adding gdbstub to the loader project but I can't test because of the bug in the gdb build. Does anyone know how to fix the nonliteral-string warning (treated as an error in the gdb Makefile)? Either that or I need to figure out how to revert the binutils submodule to an earlier version of Eric's binutils project where gdb is not built.
I'm afraid I'm stuck. I started working on adding gdbstub to the loader project but I can't test because of the bug in the gdb build. Does anyone know how to fix the nonliteral-string warning (treated as an error in the gdb Makefile)? Either that or I need to figure out how to revert the binutils submodule to an earlier version of Eric's binutils project where gdb is not built.
I don't understand why I don't get the build failure on my compiler (Ubuntu 12.04.5, 64 bit). That format is definitely a non-literal. Perhaps different versions of gcc check different members of the *printf family? Or are you using Clang?
Anyway, it appears we should be passing "--disable-werror" to the configure script to remove that -Werror. Gdb is built from the binutils script, so presumably changing the Makefile to give that option to the binutils configure will do the trick. I can look at it, but I'll be flying blind since I don't get the error.
I don't understand why I don't get the build failure on my compiler (Ubuntu 12.04.5, 64 bit). That format is definitely a non-literal. Perhaps different versions of gcc check different members of the *printf family? Or are you using Clang?
Anyway, it appears we should be passing "--disable-werror" to the configure script to remove that -Werror. Gdb is built from the binutils script, so presumably changing the Makefile to give that option to the binutils configure will do the trick. I can look at it, but I'll be flying blind since I don't get the error.
Yes, the Xcode compiler is based on Clang. I hate to use --disable-werror since that can catch lots of problems. The trouble is, the Xcode compiler is *very* picky. Anyway, I've added gdbstub to the loader submodule so it gets built along with propeller-load. I figured that would be appropriate since it uses pieces of propeller-load. I can't test it though because I can't get binutils to build until I fix this non-literal format issue.
I pushed changes to the loader submodule so that it builds and installs the gdbstub.
It seems that my push broke the TeamCity builds but I'm not sure why. I did a fresh checkout of the propeller-gcc tree and it built fine including gdbstub on my Mac.
David: Can you tell what went wrong with the TeamCity builds?
It seems that my push broke the TeamCity builds but I'm not sure why. I did a fresh checkout of the propeller-gcc tree and it built fine including gdbstub on my Mac.
David: Can you tell what went wrong with the TeamCity builds?
I looked into this further and it seems that the openspin build fails if I use "make -j 4" instead of just "make". Since I can duplicate this locally, I will try to track down what is going wrong.
I copied the ncurses source from the old propgcc repository into a new repository called propgcc-ncurses and I included that as a submodule in the propeller-gcc project. I'm not setup to do a RasperryPi build at the moment so I'd appreciate any input as to whether this fixes the RaspberryPi build. Of course, the problem with parallel builds of openspin will have to be fixed first. I started looking at this but don't immediately have a fix.
Comments
I've actually been trying to fix this anomaly for a long time. It has to do with running multi-threaded make - I don't have the dependencies set correctly so sometimes it builds in the wrong order and fails. I probably shouldn't be using "-j" in INSTALL.py but it just takes forever if I omit it.
If it will be a while before the new propeller-gcc repository is ready for prime time, would it be helpful if I put https://github.com/parallaxinc/propgcc into TeamCity? It would require a bit of extra work and space on the server, but I'm okay with that if it would prove useful.
Anyway, just wanted to let you know that it hasn't been forgotten.
I also enabled the propeller-elf-gdb build in the new binutils. We still need to move gdbstub over.
gcc -Wno-string-plus-int -Wno-deprecated-declarations -Wno-empty-body -Wno-self-assign -Wno-sometimes-uninitialized -Wno-uninitialized -I. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/common -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/config -DLOCALEDIR="\"/Users/dbetz/parallax/propeller-gcc4-build/target/share/locale\"" -DHAVE_CONFIG_H -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include/opcode -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../opcodes/.. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../readline/.. -I../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include -I../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -Werror -c -o gdb.o -MT gdb.o -MMD -MP -MF .deps/gdb.Tpo /Users/dbetz/parallax/propeller-gcc/binutils/gdb/gdb.c error: unknown warning option '-Wmissing-parameter-type' [-Werror,-Wunknown-warning-option] error: unknown warning option '-Wold-style-declaration'; did you mean '-Wout-of-line-declaration'? [-Werror,-Wunknown-warning-option]I guess I'll have to add -Wno-unknown-warning-option to fix-xcode-warnings.sh'.The protocol hasn't changed, and it seemed to work for me, so it *should* work as-is. It's always possible that I messed something up in the port, though!
That fixed it! PropWare is building stable again!
I'm afraid that killed the Raspberry Pi build
Google told me that I needed to install ncurse-dev, but when I tried, I got this:
The first command is me trying to use tab-complete to find ncurses-dev... which isn't there (the Google link I found was using yum, so I guess that was redhat right, not Ubuntu?). But then apt I try it anyway and apt is smart enough to do the right thing... but it was already done.
So my best guess is that the arm cross compiler needs its own version of the terncap library, and that isn't included in the package downloaded via the instructions on the wiki
Yes. You'll need to build ncurses for the ARM (or find a precompiled binary compatible with the raspberry pi). This has bitten us before :-(. There's a git repo for ncurses at:
git://ncurses.scripts.mit.edu/ncurses.git
It's been a while since I built it, but I seem to recall that it was pretty straightforward to build for the pi. Alternatively, you could move the files from your rasbian install over to your x86 build machine.
gcc -Wno-string-plus-int -Wno-deprecated-declarations -Wno-empty-body -Wno-self-assign -Wno-sometimes-uninitialized -Wno-uninitialized -Wno-unknown-warning-option -I. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/common -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/config -DLOCALEDIR="\"/Users/dbetz/parallax/propeller-gcc4-build/target/share/locale\"" -DHAVE_CONFIG_H -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include/opcode -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../opcodes/.. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../readline/.. -I../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include -I../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -Werror -c -o remote.o -MT remote.o -MMD -MP -MF .deps/remote.Tpo /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:5536:47: error: size argument in 'strncmp' call is a comparison [-Werror,-Wmemsize-comparison] && strncmp (p, "core", strlen ("core") != 0)) ~~~~~~~~~~~~~~~~^~~~ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:5536:11: note: did you mean to compare the result of 'strncmp' instead? && strncmp (p, "core", strlen ("core") != 0)) ^ ~ ) /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:5536:31: note: explicitly cast the argument to size_t to silence this warning && strncmp (p, "core", strlen ("core") != 0)) ^ (size_t)( ) /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:7003:37: error: format string is not a string literal [-Werror,-Wformat-nonliteral] if (vsnprintf (rs->buf, max_size, format, ap) >= max_size) ^~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/secure/_stdio.h:75:63: note: expanded from macro 'vsnprintf' __builtin___vsnprintf_chk (str, len, 0, __darwin_obsz(str), format, ap) ^ 2 errors generated.gcc -Wno-string-plus-int -Wno-deprecated-declarations -Wno-empty-body -Wno-self-assign -Wno-sometimes-uninitialized -Wno-uninitialized -Wno-unknown-warning-option -Wno-format-nonliteral -I. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/common -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/config -DLOCALEDIR="\"/Users/dbetz/parallax/propeller-gcc4-build/target/share/locale\"" -DHAVE_CONFIG_H -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include/opcode -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../opcodes/.. -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../readline/.. -I../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../bfd -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../include -I../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../libdecnumber -I/Users/dbetz/parallax/propeller-gcc/binutils/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -Werror -c -o remote.o -MT remote.o -MMD -MP -MF .deps/remote.Tpo /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:7003:37: error: format string is not a string literal [-Werror,-Wformat-nonliteral] if (vsnprintf (rs->buf, max_size, format, ap) >= max_size) ^~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/secure/_stdio.h:75:63: note: expanded from macro 'vsnprintf' __builtin___vsnprintf_chk (str, len, 0, __darwin_obsz(str), format, ap) ^ 1 error generated.I don't understand why I don't get the build failure on my compiler (Ubuntu 12.04.5, 64 bit). That format is definitely a non-literal. Perhaps different versions of gcc check different members of the *printf family? Or are you using Clang?
Anyway, it appears we should be passing "--disable-werror" to the configure script to remove that -Werror. Gdb is built from the binutils script, so presumably changing the Makefile to give that option to the binutils configure will do the trick. I can look at it, but I'll be flying blind since I don't get the error.
David: Can you tell what went wrong with the TeamCity builds?