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.
Seems to be something about the PropellerCompiler sub directory... When you build that with "make -j 4" and then build OpenSpin with "make -j 4" it works. So, something about make calling down to the sub-directory to build.
I just pushed fixes for parallel build problems with openspin and propeller-load. The Linux 64 build succeeded on TeamCity and the other builds are in progress. If this really fixes the parallel build problems, it should provide an opportunity to see whether my changes to include ncurses fixes the RaspberryPi build.
The Linux and RaspberryPi builds are working now. The Windows build fails though in building gdbstub because <windows.h> is not found. Isn't that part of MinGW? Can someone try this build on a real Windows machine to see if it fails in the same way?
I'm looking into the windows.h issue. Google sure does think it should be included with the mingw installation. I did a "find / -name windows.h" and got nothing though . I'll let you know when I find the issue.
--Edit--
Nevermind. I found it. It was hidden among a bunch of "find: `/var/log/mysql': Permission denied"
I'm looking into the windows.h issue. Google sure does think it should be included with the mingw installation. I did a "find / -name windows.h" and got nothing though . I'll let you know when I find the issue.
--Edit--
Nevermind. I found it. It was hidden among a bunch of "find: `/var/log/mysql': Permission denied"
/usr/i586-mingw32msvc/include/windows.h
I guess there must be something wrong with the Makefile. Maybe it's trying to compile gdbstub with the native x86 C compiler. I'll have to look into that later.
Thanks again for setting up this auto-build server! It certainly helps in tracking down these problems and it's great that current builds are always available. Great job!
Thanks again for setting up this auto-build server! It certainly helps in tracking down these problems and it's great that current builds are always available. Great job!
No problem! I'm glad to hear it's helping already! And to help even more, I just added a build trigger for PropWare - it will now be built after every successful build of GCC4 or, of course, when I commit to PropWare (once 5 is stable, I'll switch to that).
Well done I see gcc4 win32 has finished successfully. The others will finish shortly
What I'm not sure of is that gdb is being built. I know gdbstub is. I thought Eric said he had enabled the gdb build but it doesn't seem to be in the target bin directory after a local build.
Strange. I hope I didn't so something to revert back to before Eric's fix. I admit that working with submodules has me a bit confused at times.
Same for all of us lol.
I think the reasoning behind the wonky behavior is to get around subversions worse implementation. In svn, there are svn:externals, which are the same thing. The difference is that, when you link in another project, it links to the project itself, not a specific commit/revision number. What that means is when you create a tag, you don't get a deep-copy - only shallow. Bad news if you ever want to revert to that tag because you have no idea which commit the child module was on when the tag was created. Git fixes that... at the cost of being a royal PITA.
Most likely the wrong revision of binutils is being used by propeller-gcc. The expr.c fix and gdb build are both recent additions. We should be using the latest binutils, but it looks like we're not? That's probably my fault -- I tried to force the submodule to use the latest revision, but I probably got it wrong. Unfortunately I only have limited access to my Linux build machine right now, so it may be a while before I can fix this.
I think you were successful in updating binutils because my Mac build is now broken. :-(
This is the same set of problems I had once before when I tried to update. The first seems like a real bug in gdb:
/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))
I really think this should be:
/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)
Shall I fix it and push the the fix back to github?
The second is my compiler being picky and I don't know of a way to fix it:
/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)
I can't just add -Wno-format-nonliteral to my fix-xcode-warnings.sh file because there is an explicit -Wformat-nonliteral in the command line.
So my build is now broken until I find a way to fix this warning.
It looks like the clang build problems are fixed in the original repo, so I've merged our code with that. Could you give the new version a try?
Unfortunately, the build still fails on the Mac. I even added -Wno-unused-function to my fix-xcode-warnings.sh file and that didn't help. I'm beginning to have doubts as to the usefulness of C as a programming language. With all of the attempts to tighten the checking for buffer overrun errors and other suspect constructs, it's beginning to be impossible to compile programs without turning off all warnings. Maybe it's time to move on to a better-designed language. Would that be D?
Maybe it's time to move on to a better-designed language. Would that be D?
I'm all for it
In other news, I'm having issues with the server that TeamCity is running on. The space seems to be getting out of control and another 26 GB were used in a matter of a couple hours this morning, so I just turned off TeamCity and rebooted the OS. I'll let you know when it's back up and running again.
If I delete the references to gdb in the Makefile then everything else builds fine on the Mac. Is there an easy way to remove gdb from the Mac build until these errors get sorted out?
If I delete the references to gdb in the Makefile then everything else builds fine on the Mac. Is there an easy way to remove gdb from the Mac build until these errors get sorted out?
I think passing the --disable-gdb command line option to the binutils configure script should do that.
I think passing the --disable-gdb command line option to the binutils configure script should do that.
Thanks! That worked. I pushed a change to the propeller-gcc Makefile to use that option when building on the Mac. The other platforms will continue to build gdb.
Any ideas for TeamCity plugins? JetBrains is holding a contest and every entry automatically gets a free license to a JetBrains product. I'd love to enter but can't think of anything I want it to do!
Any ideas for TeamCity plugins? JetBrains is holding a contest and every entry automatically gets a free license to a JetBrains product. I'd love to enter but can't think of anything I want it to do!
Comments
Seems to be something about the PropellerCompiler sub directory... When you build that with "make -j 4" and then build OpenSpin with "make -j 4" it works. So, something about make calling down to the sub-directory to build.
dgately
I'm looking into the windows.h issue. Google sure does think it should be included with the mingw installation. I did a "find / -name windows.h" and got nothing though
--Edit--
Nevermind. I found it. It was hidden among a bunch of "find: `/var/log/mysql': Permission denied"
/usr/i586-mingw32msvc/include/windows.h
Thanks again for setting up this auto-build server! It certainly helps in tracking down these problems and it's great that current builds are always available. Great job!
No problem! I'm glad to hear it's helping already! And to help even more, I just added a build trigger for PropWare - it will now be built after every successful build of GCC4 or, of course, when I commit to PropWare (once 5 is stable, I'll switch to that).
Well done
Nope. Somewhere in propgcc. Eric mentioned the assembler but expr.c is in binutils I think.
Same for all of us lol.
I think the reasoning behind the wonky behavior is to get around subversions worse implementation. In svn, there are svn:externals, which are the same thing. The difference is that, when you link in another project, it links to the project itself, not a specific commit/revision number. What that means is when you create a tag, you don't get a deep-copy - only shallow. Bad news if you ever want to revert to that tag because you have no idea which commit the child module was on when the tag was created. Git fixes that... at the cost of being a royal PITA.
This is the same set of problems I had once before when I tried to update. The first seems like a real bug in gdb:
/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))I really think this should be:
/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)Shall I fix it and push the the fix back to github?
The second is my compiler being picky and I don't know of a way to fix it:
/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)I can't just add -Wno-format-nonliteral to my fix-xcode-warnings.sh file because there is an explicit -Wformat-nonliteral in the command line.So my build is now broken until I find a way to fix this warning.
gcc -Wno-string-plus-int -Wno-deprecated-declarations -Wno-empty-body -Wno-self-assign -Wno-sometimes-uninitialized -Wno-uninitialized -Wno-unknown-warning-option -Wno-unused-function -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/Users/dbetz/parallax/propeller-gcc/binutils/gdb/../zlib -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 -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wpointer-sign -Wmissing-prototypes -Wdeclaration-after-statement -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:2590:1: error: unused function 'VEC_thread_item_t_embedded_size' [-Werror,-Wunused-function] DEF_VEC_O(thread_item_t); ^ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/common/vec.h:435:20: note: expanded from macro 'DEF_VEC_O' VEC_T(T); \ ^ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/common/vec.h:863:22: note: expanded from macro '\ DEF_VEC_FUNC_O' static inline size_t VEC_OP (T,embedded_size) \ ^ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP' #define VEC_OP(T,OP) VEC_##T##_##OP ^ <scratch space>:42:1: note: expanded from here VEC_thread_item_t_embedded_size ^ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/remote.c:2590:1: error: unused function 'VEC_thread_item_t_embedded_init' [-Werror,-Wunused-function] /Users/dbetz/parallax/propeller-gcc/binutils/gdb/common/vec.h:435:20: note: expanded from macro 'DEF_VEC_O' VEC_T(T); \ ^ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/common/vec.h:869:20: note: expanded from macro '\ DEF_VEC_FUNC_O' static inline void VEC_OP (T,embedded_init) \ ^ /Users/dbetz/parallax/propeller-gcc/binutils/gdb/common/vec.h:399:22: note: expanded from macro 'VEC_OP' #define VEC_OP(T,OP) VEC_##T##_##OP ^ <scratch space>:46:1: note: expanded from here VEC_thread_item_t_embedded_init ^I was wondering when the mess that causes will show up
I'm all for it
In other news, I'm having issues with the server that TeamCity is running on. The space seems to be getting out of control and another 26 GB were used in a matter of a couple hours this morning, so I just turned off TeamCity and rebooted the OS. I'll let you know when it's back up and running again.
Builds are running again and space is stable. Going well so far.
Edit
Whoo hoo! All green again
I think passing the --disable-gdb command line option to the binutils configure script should do that.
GCC4
x86-64 Linux: http://david.zemon.name:8111/repository/download/PropGCC5_Gcc4linuxX64/.lastSuccessful/propellergcc-alpha_v1_9_0-gcc4-linux-x64.tar.gz?guest=1
RPi: http://david.zemon.name:8111/repository/download/PropGCC5_Gcc4rpi/.lastSuccessful/propellergcc-alpha_v1_9_0-gcc4-rpi.tar.gz?guest=1
Win32: http://david.zemon.name:8111/repository/download/PropGCC5_Gcc4win32/.lastSuccessful/propellergcc-alpha_v1_9_0-gcc4-win32.zip?guest=1
GCC5
x86-64 Linux: http://david.zemon.name:8111/repository/download/PropGCC5_Gcc5linuxX64/.lastSuccessful/propellergcc-alpha_v1_9_0-gcc5-linux-x64.tar.gz?guest=1
RPi: http://david.zemon.name:8111/repository/download/PropGCC5_Gcc5rpi/.lastSuccessful/propellergcc-alpha_v1_9_0-gcc5-rpi.tar.gz?guest=1
Win32: http://david.zemon.name:8111/repository/download/PropGCC5_Gcc5win32/.lastSuccessful/propellergcc-alpha_v1_9_0-gcc5-win32.zip?guest=1
Full info here
https://www.jetbrains.com/teamcity/specials/teamcity/teamcity_plugin_contest.jsp
I developed libpropeller by writing unit tests for all the code:
https://github.com/libpropeller/libpropeller/wiki/Unit-Testing
I had to use external hardware to do that, so it would be pretty cool if the build server automatically ran hardware unit tests.
That would be very cool. Unfortunately, I don't have access to the physical server. We would need propeller-load to work over an ssh tunnel.