Getting closer. Looks like openspin is the last remaining piece
I submitted the openspin changes but they haven't been merged yet. I'm also not completely happy with the way the spin2cpp, spinsim, and openspin Makefiles work. They store their build artifacts in the source tree and don't provide a way to override that on the make command line. I sent email to Eric to see if we can make that a bit more flexible so that the artifacts can be put in the same xxx-build tree that is used by the other components like gcc, binutils, etc.
Ugh. I have changes in pretty much all of the Makefiles to push. I can push the ones for propeller-gcc and spinsim but I need to get approval for spin2cpp and openspin. The propeller-gcc build might be suboptimal until I get that done.
I tried using gcc 5 for the first time tonight. It didn't go well. PropWare makes use of cstdint and other C++-style includes which aren't available
Yeah, I think it's a work in progress at the present. If you switch back to gcc4, let me know if you have any trouble with binutils or the library. Those are new even though the compiler itself is still the version from the propgcc repository.
Oh! Glad you asked. I just tried gcc4 from this new repo for the first time and it too is missing cstdint and other related C++ stuffs
Okay, I can probably fix that. Eric skips the build of the standard c++ library because it doesn't work with the new compiler yet. Or, maybe it doesn't work with the new binutils. I guess I'd better check that. In any case, I can add it to the list of targets to build when gcc4 is being used as the compiler.
Okay, I can probably fix that. Eric skips the build of the standard c++ library because it doesn't work with the new compiler yet. Or, maybe it doesn't work with the new binutils. I guess I'd better check that. In any case, I can add it to the list of targets to build when gcc4 is being used as the compiler.
Well, that doesn't work either. I think I'm going to have to make propeller-gcc use the old binutils and library as well. The problem is, the P2 support has been removed from binutils but it's still in the old compiler so the makefile tries to generate libstdc++ P2 builds and fails. I don't have time to do that tonight. Maybe you should make your gcc4 builds use the propgcc project for now.
I tried using gcc 5 for the first time tonight. It didn't go well. PropWare makes use of cstdint and other C++-style includes which aren't available
I haven't really been following this conversation, but this did catch my eye. If it turns out to be a permanent problem could you post up a few notes on what needs to change from GCC<now> to GCC5?
I'm waiting for everything to settle down, then I want to compare binary sizes with the new version.
Roy merged my changes to the openspin Makefile but then I found a few other things that needed to be changed. I now have push access to OpenSpin so I fixed them myself and also updated the propeller-gcc Makefile accordingly. I think this should fix the build and the gcc4 build should now include libstdc++ as well.
Roy merged my changes to the openspin Makefile but then I found a few other things that needed to be changed. I now have push access to OpenSpin so I fixed them myself and also updated the propeller-gcc Makefile accordingly. I think this should fix the build and the gcc4 build should now include libstdc++ as well.
FYI, I did a clean checkout and default build (for gcc4) and it completed successfully.
Overall it looks like things are going well for TeamCity. I think builds have stabilized for the most part. Windows builds are still failing due to not finding openspin/openspin.exe though.
Overall it looks like things are going well for TeamCity. I think builds have stabilized for the most part. Windows builds are still failing due to not finding openspin/openspin.exe though.
Is this a naming problem? Is there an openspin/openspin? Did I mess up the adding of the .exe extension?
Ah, I lied. Sorry. The problem is that openspin.exe isn't be recognized as a command. It exists and has the correct extension, but the error is "command not found" from the loader module
[22:46:11][Step 3/5] make[1]: Entering directory `/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/71b5f7d6548ebb35/loader'
[22:46:11][Step 3/5] TOOLCC: i586-mingw32msvc-gcc
[22:46:11][Step 3/5] CFLAGS: -DMINGW -Wall -Isrc/common -Isrc/runtime -Isrc/loader
[22:46:11][Step 3/5] LDFLAGS: -DMINGW -Wall -Isrc/common -Isrc/runtime -Isrc/loader
[22:46:11][Step 3/5] SPIN:
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/bin/msys/bin2c.exe
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/propeller-load.o
[22:46:11][Step 3/5] src/loader.c: In function ‘WriteFileToSDCard’:
[22:46:11][Step 3/5] src/loader.c:1354: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘size_t’
[22:46:11][Step 3/5] src/loader.c:1361: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘size_t’
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/loader.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/lmm-image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/xmm-image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/xmm-image2.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/pex-image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/loadelf.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/packet.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/PLoadLib.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/p1image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/config.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/expr.o
[22:46:12][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/system.o
[22:46:12][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/port.o
[22:46:12][Step 3/5] make[1]: openspin.exe: Command not found
[22:46:12][Step 3/5] make[1]: *** [/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/serial_helper.binary] Error 127
[22:46:12][Step 3/5] make: *** [/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/loader-built] Error 2
[22:46:12][Step 3/5] make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/71b5f7d6548ebb35/loader'
[22:46:12][Step 3/5] Process exited with code 2
Ah, I lied. Sorry. The problem is that openspin.exe isn't be recognized as a command. It exists and has the correct extension, but the error is "command not found" from the loader module
[22:46:11][Step 3/5] make[1]: Entering directory `/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/71b5f7d6548ebb35/loader'
[22:46:11][Step 3/5] TOOLCC: i586-mingw32msvc-gcc
[22:46:11][Step 3/5] CFLAGS: -DMINGW -Wall -Isrc/common -Isrc/runtime -Isrc/loader
[22:46:11][Step 3/5] LDFLAGS: -DMINGW -Wall -Isrc/common -Isrc/runtime -Isrc/loader
[22:46:11][Step 3/5] SPIN:
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/bin/msys/bin2c.exe
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/propeller-load.o
[22:46:11][Step 3/5] src/loader.c: In function ‘WriteFileToSDCard’:
[22:46:11][Step 3/5] src/loader.c:1354: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘size_t’
[22:46:11][Step 3/5] src/loader.c:1361: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘size_t’
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/loader.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/lmm-image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/xmm-image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/xmm-image2.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/pex-image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/loadelf.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/packet.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/PLoadLib.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/p1image.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/config.o
[22:46:11][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/expr.o
[22:46:12][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/system.o
[22:46:12][Step 3/5] /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/port.o
[22:46:12][Step 3/5] make[1]: openspin.exe: Command not found
[22:46:12][Step 3/5] make[1]: *** [/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/obj/msys/serial_helper.binary] Error 127
[22:46:12][Step 3/5] make: *** [/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/propeller-gcc4-win32-build/loader/loader-built] Error 2
[22:46:12][Step 3/5] make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/71b5f7d6548ebb35/loader'
[22:46:12][Step 3/5] Process exited with code 2
Okay, I guess this is the problem of trying to use the target executables to build on the host. Also, I found a problem with invoking the sub-makefiles for openspin, spin2cpp, and spinsim. I'm trying out a fix for that now. It looks like I need to setup an environment for generating Windows builds.
Okay, I guess this is the problem of trying to use the target executables to build on the host. Also, I found a problem with invoking the sub-makefiles for openspin, spin2cpp, and spinsim. I'm trying out a fix for that now. It looks like I need to setup an environment for generating Windows builds.
Ha! I must be more tired than I thought. I didn't even make the connection, that it shouldn't even be trying to run an exe file :P
I just pushed my change to correctly (I hope!) invoke the openspin, spin2cpp, and spinsim Makefiles. However, I don't think that will fix the openspin.exe issue. I'm not sure why that is even happening. I'll try to get a cross build Linux environment setup to diagnose this problem but I won't be able to do it today. Sorry for the problems.
Life is pretty good on the gcc front I think. The commit you pushed yesterday built fine for four of the six the builds. Windows still failing, as you suspected.
Unfortunately, building PropWare now fails (using gcc4) with the following message:
Life is pretty good on the gcc front I think. The commit you pushed yesterday built fine for four of the six the builds. Windows still failing, as you suspected.
Unfortunately, building PropWare now fails (using gcc4) with the following message:
Okay, this is probably due to using the new binutils. We should let Eric Smith know about this problem with colon labels. Is that the only problem you've seen with building PropWare?
Okay, this is probably due to using the new binutils. We should let Eric Smith know about this problem with colon labels. Is that the only problem you've seen with building PropWare?
So far, with GCC4, yes. GCC5 still doesn't have C++ support, but you mentioned you're already aware of that so I'm not worried.
Where does CMake put its build output? I tried building PropWare and got a failure, but I'm not sure if it's the same one.
I don't think it logs verbose output. If you run make without arguments, you only get warnings and errors. If you run "make VERBOSE=1" then it echoes everything to stdout before running. I hope that answers your question... let me know if not.
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 tried running propeller-elf-gcc directly on seeedtftfast_as.S, and it assembles without any error.
If you do:
propeller-elf-gcc -I.. -c seeedtftfast_as.S
in the PropWare directory, does it work, or do you get the same error?
Are you running a 32 bit version of Linux? If so, perhaps there's some kind of int/pointer size issue going on -- I have 64 bits here.
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 tried running propeller-elf-gcc directly on seeedtftfast_as.S, and it assembles without any error.
If you do:
propeller-elf-gcc -I.. -c seeedtftfast_as.S
in the PropWare directory, does it work, or do you get the same error?
Are you running a 32 bit version of Linux? If so, perhaps there's some kind of int/pointer size issue going on -- I have 64 bits here.
Eric
Here's the result
dzweb@davidzemonname:~/PropWare/PropWare$ propeller-elf-gcc -I/var/www/vhosts/david.zemon.name/PropWare seeedtftfast_as.S
seeedtftfast_as.S: Assembler messages:
seeedtftfast_as.S:127: Internal error!
Assertion failure in operand at /var/www/vhosts/david.zemon.name/TeamCity/buildAgent/work/71b5f7d6548ebb35/binutils/gas/expr.c line 1386.
Please report this bug.
dzweb@davidzemonname:~/PropWare/PropWare$
The server is 64-bit Ubuntu 14.04. I'll try this on my local machine when I get home.
Comments
I tried using gcc 5 for the first time tonight. It didn't go well. PropWare makes use of cstdint and other C++-style includes which aren't available
I haven't really been following this conversation, but this did catch my eye. If it turns out to be a permanent problem could you post up a few notes on what needs to change from GCC<now> to GCC5?
I'm waiting for everything to settle down, then I want to compare binary sizes with the new version.
And when i log into the server:
FYI, I did a clean checkout and default build (for gcc4) and it completed successfully.
Ha! I must be more tired than I thought. I didn't even make the connection, that it shouldn't even be trying to run an exe file :P
Unfortunately, building PropWare now fails (using gcc4) with the following message:
Here is the line that caused the failure:
Also, I'll get the Windows cross build working tonight.
No, it hasn't unfortunately.
So far, with GCC4, yes. GCC5 still doesn't have C++ support, but you mentioned you're already aware of that so I'm not worried.
Where does CMake put its build output? I tried building PropWare and got a failure, but I'm not sure if it's the same one.
It builds with 2408. I haven't tried anything newer.
I don't think it logs verbose output. If you run make without arguments, you only get warnings and errors. If you run "make VERBOSE=1" then it echoes everything to stdout before running. I hope that answers your question... let me know if not.
If you do: in the PropWare directory, does it work, or do you get the same error?
Are you running a 32 bit version of Linux? If so, perhaps there's some kind of int/pointer size issue going on -- I have 64 bits here.
Eric
Here's the result
The server is 64-bit Ubuntu 14.04. I'll try this on my local machine when I get home.