That's what I meant by "I'm working on updating git". I'm currently sharing a VPS with my dad, but git was the last straw so I'm jumping ship and getting my own VPS where I'll have root privileges and can update/blow things up however I please
I just updated the propeller-gcc repository to include the old version of gcc from the default branch of the old propgcc project as well as Eric's new version based on GCC 5. You can select either by setting a variable at the top of the Makefile. The default is to use the old version of GCC. I've also switched to including spinsim from the Parallax github account rather than from my own.
Finally got my new server up and running. Now running git 1.9 and I have full root privileges this time around.
Unfortunately, I now get the following error:
...
...
make[3]: Entering directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils'
gcc -g -O2 -o sysinfo sysinfo.o syslex_wrap.o
syslex_wrap.o: In function `main':
/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils/./syslex.c:1: multiple definition of `main'
sysinfo.o:/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils/sysinfo.c:1: first defined here
collect2: error: ld returned 1 exit status
make[3]: *** [sysinfo] Error 1
make[3]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils'
make[2]: *** [all-binutils] Error 2
make[2]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils'
make: *** [/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils-built] Error 2
dzweb@davidzemonname:~/propgcc5/src$
It's possible this is the result of some weird stuff getting mixed up after the migration, and to help aleviate that I wiped the whole directory and cloned the repo from scratch again. Same problem. I haven't tried on my local machine yet. Are you seeing this error?
I just did the following sequence of commands on the Mac and it resulted in a successful build:
git clone https://github.com/dbetz/propeller-gcc.git
cd propeller-gcc
git submodule init
git submodule update
cd gcc
./contrib/download_prerequisites
cd ..
source fix-xcode-warnings.sh
make
I guess I'll have to try the same thing under Linux to duplicate your problem.
Looks like it was a dependency issue. Being a new box, I didn't have most of the dependencies. I being such an odd error, I was expecting that at all - I would have thought the configure script would catch that stuff (like mpc). The specific issue with syslex.c and sysinfo.c was missing flex/bison.
Issue after issue with this. It's compiling fine locally but I can't get it to run on the server still. The error output is as follows
make[3]: Entering directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils'
gcc -c -I. -I/var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -Wno-error /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c
In file included from /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c:25:0:
syslex.l: In function ‘yylex’:
syslex.l:55:2: error: ‘yylval’ undeclared (first use in this function)
syslex.l:55:2: note: each undeclared identifier is reported only once for each function it appears in
syslex.l:58:16: error: ‘NAME’ undeclared (first use in this function)
In file included from /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c:25:0:
syslex.l:63:10: error: ‘NUMBER’ undeclared (first use in this function)
In file included from /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c:25:0:
syslex.l:72:23: error: ‘UNIT’ undeclared (first use in this function)
In file included from /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c:25:0:
syslex.l:77:28: error: ‘TYPE’ undeclared (first use in this function)
In file included from /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c:25:0:
syslex.l:84:10: error: ‘COND’ undeclared (first use in this function)
In file included from /var/www/vhosts/david.zemon.name/propgcc5/src/binutils/binutils/syslex_wrap.c:25:0:
syslex.l:85:10: error: ‘REPEAT’ undeclared (first use in this function)
make[3]: *** [syslex_wrap.o] Error 1
make[3]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils'
make[2]: *** [all-binutils] Error 2
make[2]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils'
make: *** [/var/www/vhosts/david.zemon.name/propgcc5/propeller-gcc-build/binutils/binutils-built] Error 2
dzweb@davidzemonname:~/propgcc5/src$
--Edit--
I guess a mistake by apt, though I'm skeptical of that since I've never seen apt just ignore a dependency before. In any case, explicitly installing bison fixed the issue, as suggested here.
Okay, one final request I think. What do I name the package files to differentiate between gcc4 and gcc5? Maybe gcc5 is propgcc 2.0? And how can the release folder and its contents be modified to make this work automagically?
Okay, one final request I think. What do I name the package files to differentiate between gcc4 and gcc5? Maybe gcc5 is propgcc 2.0? And how can the release folder and its contents be modified to make this work automagically?
The idea was that PropGCC 2.0 would be a release based on what is currently in the master branch. That doesn't include gcc5. I don't think we've gotten far enough to think about what to call a version that includes the new gcc toolchain. Maybe Jeff will comment on release plans. Most of this depends on finding resources to do sufficient testing to make a release.
It is certainly my hope that providing always-up-to-date builds of GCC will aid in testing... but I can't package the results of these builds without a unique name for each and every build configuration. I guess for now I'll just stick the value of "GCCDIR" in as part of the archive name.
It is certainly my hope that providing always-up-to-date builds of GCC will aid in testing... but I can't package the results of these builds without a unique name for each and every build configuration. I guess for now I'll just stick the value of "GCCDIR" in as part of the archive name.
It's kind of unfortunately that I didn't call the directory containing gcc5 by that name instead of just "gcc". I'm not sure how to rename a git submodule though.
It looks like, when I do a fresh checkout from the repo, it's checking out the previous version of the loader (with the bad version of bin2c.c). I'm confirming that now, outside of TeamCity, but I'm 99% sure that's the latest issue I've been having. Git submodules seem like such a good idea, but they're sure not working as I expect them too...
It looks like, when I do a fresh checkout from the repo, it's checking out the previous version of the loader (with the bad version of bin2c.c). I'm confirming that now, outside of TeamCity, but I'm 99% sure that's the latest issue I've been having. Git submodules seem like such a good idea, but they're sure not working as I expect them too...
--Edit--
Just confirmed. That is indeed the case.
I probably forgot to update the submodules after changing the loader. I'll do that later today. I have to head to the airport now.
Great! Glad to know we're on the same page finally. This is good. I think we're getting really close to having TeamCity stable. Once it is so, I can configure it to send emails when a build fails and fixes can be applied much more quickly. That is, of course, assuming the authors of the programs are willing to receive email notifications upon erroneous builds.
Great! Glad to know we're on the same page finally. This is good. I think we're getting really close to having TeamCity stable. Once it is so, I can configure it to send emails when a build fails and fixes can be applied much more quickly. That is, of course, assuming the authors of the programs are willing to receive email notifications upon erroneous builds.
Sorry I pushed the change to spin2cpp without doing a verification build first. It didn't occur to me that it would break the build. If I don't hear from Eric sooner, I'll try to fix this tonight.
I just merged Eric's Makefile change and verified that it fixes the build. I've pushed the changes to github so your build should work now. I still need to update the openspin Makefile to support cross builds. The spinsim project also needs updating but I'm not sure if Dave Hein will do it or if I will. I'll have to check with him as he owns that module.
It looks like you set up the spinsim project with version 0.75, which is the latest version I posted. Why would this need to be updated? Spinsim is also in the PropGCC project. Should this be removed from there so there is only one repository for it?
It looks like you set up the spinsim project with version 0.75, which is the latest version I posted. Why would this need to be updated? Spinsim is also in the PropGCC project. Should this be removed from there so there is only one repository for it?
The propgcc project will eventually go away in favor of this new propeller-gcc project that includes the subprojects by reference rather than having private copies of them. The only thing that needs to be done to spinsim and openspin as well is to convert the makefile to support cross compilation. I can do that if you want. It's mostly making sure you write your output to $(BUILD) and use the compiler in $(CC).
Windows and Linux builds of gcc5 have both just finished successfully I'm still working out how best to publish them, as I don't like copying to my downloads folder where you have no way of knowing which commit they came from
Comments
That's what I meant by "I'm working on updating git". I'm currently sharing a VPS with my dad, but git was the last straw so I'm jumping ship and getting my own VPS where I'll have root privileges and can update/blow things up however I please
Unfortunately, I now get the following error:
It's possible this is the result of some weird stuff getting mixed up after the migration, and to help aleviate that I wiped the whole directory and cloned the repo from scratch again. Same problem. I haven't tried on my local machine yet. Are you seeing this error?
For instance,
BUILD?=$(realpath ..)/propeller-$(GCCDIR)-build
Then there's no conflict in build directories across all the different build types
which happens to look exactly like this bug
--Edit--
I guess a mistake by apt, though I'm skeptical of that since I've never seen apt just ignore a dependency before. In any case, explicitly installing bison fixed the issue, as suggested here.
It looks like, when I do a fresh checkout from the repo, it's checking out the previous version of the loader (with the bad version of bin2c.c). I'm confirming that now, outside of TeamCity, but I'm 99% sure that's the latest issue I've been having. Git submodules seem like such a good idea, but they're sure not working as I expect them too...
--Edit--
Just confirmed. That is indeed the case.
Then I get this when I compile outside of TeamCity
[code]make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/src/openspin'
Installing openspin
Building spin2cpp
make[1]: Entering directory `/var/www/vhosts/david.zemon.name/propgcc5/src/spin2cpp'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/var/www/vhosts/david.zemon.name/propgcc5/src/spin2cpp'
Installing spin2cpp
cp: cannot stat