I don'the build things as much as you guys do but it seems to me a list of dependencies is more common and having a package carry along all the extra baggage it needs is unusual and a source of problems. I vote for splitting things up.
I just pushed an update to the propeller-gcc project to include spinsim in the build. For the time being, I'm hosting spinsim in my github account but I intend to ask Parallax if it is okay to move it to the official Parallax repository. I think propeller-gcc is usable now. It should build gcc, binutils, lib, spin2cpp, spinsim, and propeller-load. The only thing it doesn't currently include is gdb and the demos directory. The demos directory would be easy to add although I should probably go through it to make sure all of the demos actually work. There is more work to be done before gdb can be added as it requires updating to work with the new gcc compiler.
Sorry for the quiet from me. David, your latest commit has things working over here again, and much better than before (and faster). I'll have it all in teamcity soon...
I've removed propgcc from my path and, unsurprisingly, it fails to cross compile. What I wasn't expecting was complaints about GMP, MPFR, and MPC. I ran make a second time, after the failure, to shorten the output:
dzweb@zemon1204:~/propgcc5/src$ make CROSS=win32
Makefile:49: BUILD directory is /var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-win32-build
Makefile:53: PREFIX is /var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-win32-build/target
Makefile:57: INSTALL directory is /opt/parallax
Makefile:93: OS msys detected.
Makefile:112: PropGCC version is propellergcc-alpha_v1_9_0_.
Makefile:116: BugURL is http://code.google.com/p/propgcc/issues.
Configuring gcc
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i586-pc-mingw32msvc
checking target system type... propeller-parallax-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for libatomic support... no
checking for libcilkrts support... no
checking for libitm support... no
checking for libsanitizer support... no
checking for libvtv support... no
checking for i586-mingw32msvc-gcc... i586-mingw32msvc-gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i586-mingw32msvc-gcc accepts -g... yes
checking for i586-mingw32msvc-gcc option to accept ISO C89... none needed
checking for i586-mingw32msvc-g++... i586-mingw32msvc-g++
checking whether we are using the GNU C++ compiler... yes
checking whether i586-mingw32msvc-g++ accepts -g... yes
checking whether g++ accepts -static-libstdc++ -static-libgcc... no
checking for i586-mingw32msvc-gnatbind... no
checking for gnatbind... no
checking for i586-mingw32msvc-gnatmake... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for objdir... .libs
checking for the correct version of gmp.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
make: *** [/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-win32-build/gcc/gcc-configured] Error 1
dzweb@zemon1204:~/propgcc5/src$
Does that require editing the makefile to pass them to the correct configure script or is there some way to pass them in as parameters to make? I'm getting
So close! Have you tried cross-compiling for windows yet? Looks like openspin is 99% there...
dzweb@zemon1204:~/propgcc5/src$ make CROSS=win32
Makefile:49: BUILD directory is /var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-win32-build
Makefile:53: PREFIX is /var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-win32-build/target
Makefile:57: INSTALL directory is /opt/parallax
Makefile:93: OS msys detected.
Makefile:112: PropGCC version is propellergcc-alpha_v1_9_0_.
Makefile:116: BugURL is http://code.google.com/p/propgcc/issues.
Building openspin
make[1]: Entering directory `/var/www/vhosts/david.zemon.name/propgcc5/src/openspin'
g++ -o openspin -Wall -g -static SpinSource/openspin.o SpinSource/flexbuf.o SpinSource/preprocess.o SpinSource/textconvert.o SpinSource/pathentry.o SpinSource/objectheap.o PropellerCompiler/libopenspin.a
make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/src/openspin'
Installing openspin
cp: cannot stat `openspin/openspin.exe': No such file or directory
make: *** [openspin] Error 1
dzweb@zemon1204:~/propgcc5/src$
Ummm.... what files are in the openspin directory? Is there any executable generated? Maybe the Makefile for openspin fails to give the executable a .exe extension for Windows?
FYI, I must moved propgcc to the Parallax github account along with spinsim and spinwrap. You will no longer find them in my github account. However, propeller-gcc is still in my account while we work on stabilizing it.
FYI, I must moved propgcc to the Parallax github account along with spinsim and spinwrap. You will no longer find them in my github account. However, propeller-gcc is still in my account while we work on stabilizing it.
Good to know. I'm certainly less interested in making the old propgcc work in teamcity now that the new version is becoming stable.
A quick look at OpenSpin's Makefile and it appears it isn't set up for cross-compilation at all
Yes, I imagine that is true. I don't think the spin2cpp Makefile is either although Eric has said he will fix that. I guess that is one disadvantage of pulling code from the official repositories. It means that you are working with code you don't control. I guess I should ask Roy about adding cross compilation support to the openspin Makefile as well.
Yes, I imagine that is true. I don't think the spin2cpp Makefile is either although Eric has said he will fix that. I guess that is one disadvantage of pulling code from the official repositories. It means that you are working with code you don't control. I guess I should ask Roy about adding cross compilation support to the openspin Makefile as well.
I just got permission to update the openspin Makefile to support cross compilation. Unfortunately, I won't be able to do it tonight. I'll try to get it done tomorrow.
64-bit linux distro is getting close to functional and published. Hopefully I can fix the issue I'm running into with teamcity before the night is out...
This requires a bit of work changing the internal symbols used to refer to the binary blob but shouldn't be too difficult.
Ummm... It isn't quite as easy as that I guess. The command I gave above will create a Propeller object file but I need an x86 object file that I can link with other host objects. I'll have to see if there is an x86 build of objcopy available on all of our platforms.
Because I won't be able to get to switching over to objcopy until tonight, I've merged your change to bin2c to unblock your build.
Thanks.
And... now... the seemly impossible task. How do we get the root project to update its children? If you take a look at the commit hashes, propeller-gcc is still pointing to the "old" version of propeller-load without my fix. The branch/commit information isn't stored in /.gitmodules, since that just contains a URL and local path. It doesn't *appear* to be stored in /.git/config since that just has a module name and URL. I'm lost
And... now... the seemly impossible task. How do we get the root project to update its children? If you take a look at the commit hashes, propeller-gcc is still pointing to the "old" version of propeller-load without my fix. The branch/commit information isn't stored in /.gitmodules, since that just contains a URL and local path. It doesn't *appear* to be stored in /.git/config since that just has a module name and URL. I'm lost
Comments
How do I keep the submodules up-to-date? They aren't pulling from branches by default, so I can't run git-pull on them.
https://gcc.gnu.org/wiki/InstallingGCC
However, why not just use the script that comes with gcc to install those libraries under propeller-gcc/gcc?
Because I forgot about that. Seems to be working now.
Yep, looks like the Makefile isn't adding the .exe extension
Good to know. I'm certainly less interested in making the old propgcc work in teamcity now that the new version is becoming stable.
A quick look at OpenSpin's Makefile and it appears it isn't set up for cross-compilation at all
64-bit linux distro is getting close to functional and published. Hopefully I can fix the issue I'm running into with teamcity before the night is out...
https://github.com/dbetz/propeller-load/pull/1
Edit: Yes, it looks like bin2c can be replaced by; This requires a bit of work changing the internal symbols used to refer to the binary blob but shouldn't be too difficult.
Thanks.
And... now... the seemly impossible task. How do we get the root project to update its children? If you take a look at the commit hashes, propeller-gcc is still pointing to the "old" version of propeller-load without my fix. The branch/commit information isn't stored in /.gitmodules, since that just contains a URL and local path. It doesn't *appear* to be stored in /.git/config since that just has a module name and URL. I'm lost
Looks like maybe the submodules could be removed and then re-added with this instead (based on this SO answer)
DOH!
I'd like to avoid that. The more automated the better.