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
Nothing. I just had to talk with my dad about security. Problem solved now.
You can visit TeamCity directly now (click "Login as guest") and download builds from there. If you click on a specific run configuration, you can download past builds as well. Each build tells you exactly what commits were incorporated into that build, so it becomes very obvious what you're downloading. You can also preview the contents of the archive prior to downloading.
"PropGCC" is the old propgcc repo. "PropGCC5" is the new propeller-gcc repo. I will delete the "PropGCC" project as soon as I iron out a few more issues with PropGCC5 and then rename PropGCC5 to PropGCC (I created PropGCC5 before you added gcc4 as another submodule).
Nothing. I just had to talk with my dad about security. Problem solved now.
You can visit TeamCity directly now (click "Login as guest") and download builds from there. If you click on a specific run configuration, you can download past builds as well. Each build tells you exactly what commits were incorporated into that build, so it becomes very obvious what you're downloading. You can also preview the contents of the archive prior to downloading.
"PropGCC" is the old propgcc repo. "PropGCC5" is the new propeller-gcc repo. I will delete the "PropGCC" project as soon as I iron out a few more issues with PropGCC5 and then rename PropGCC5 to PropGCC (I created PropGCC5 before you added gcc4 as another submodule).
Are you not building propeller-gcc using the default gcc4 option? The gcc5 compiler is still a work in progress but the gcc4 compiler in the propeller-gcc tree is the same compiler that exists in the propgcc repository. I'd like to get some testing done on that so we can validate the propeller-gcc project and eventually get rid of the propgcc project.
I like bleeding edge stuff, so I was more interested in GCC5 first. Next is GCC4. The windows build is also being rebuilt as it includes files from both gcc 4 and 5 lol
Any objection to using tar.gz instead of tar.bz2 for linux builds? TeamCity doesn't appear to have a bz2 library, so it won't let you preview bz2 archives
Any objection to using tar.gz instead of tar.bz2 for linux builds? TeamCity doesn't appear to have a bz2 library, so it won't let you preview bz2 archives
Fine by me. And thanks for taking on the task of creating these builds!!!
The builds are huge! Any idea why the installation folder looks like this?
dzweb@davidzemonname:~/TeamCity/buildAgent/work/71b5f7d6548ebb35/install-win32/parallax/libexec/gcc/propeller-elf/5.0.0$ ls -alh
total 717M
drwxr-xr-x 4 dzweb psacln 4.0K Mar 31 20:29 .
drwxr-xr-x 3 dzweb psacln 4.0K Mar 31 20:29 ..
drwxr-xr-x 2 dzweb psacln 4.0K Mar 31 20:29 install-tools
drwxr-xr-x 2 dzweb psacln 4.0K Mar 31 20:29 plugin
-rwxr-xr-x 1 dzweb psacln 140M Mar 31 20:29 cc1
-rwxr-xr-x 1 dzweb psacln 143M Mar 31 20:29 cc1obj
-rwxr-xr-x 1 dzweb psacln 162M Mar 31 20:29 cc1plus
-rwxr-xr-x 1 dzweb psacln 2.2M Mar 31 20:29 collect2
-rwxr-xr-x 1 dzweb psacln 139M Mar 31 20:29 f951
-rwxr-xr-x 1 dzweb psacln 1.1K Mar 31 20:29 liblto_plugin.la
lrwxrwxrwx 1 dzweb psacln 22 Mar 31 20:29 liblto_plugin.so -> liblto_plugin.so.0.0.0
lrwxrwxrwx 1 dzweb psacln 22 Mar 31 20:29 liblto_plugin.so.0 -> liblto_plugin.so.0.0.0
-rwxr-xr-x 1 dzweb psacln 335K Mar 31 20:29 liblto_plugin.so.0.0.0
-rwxr-xr-x 1 dzweb psacln 130M Mar 31 20:29 lto1
-rwxr-xr-x 1 dzweb psacln 2.5M Mar 31 20:29 lto-wrapper
The source directory is ~/TeamCity/buildAgent/work/71b5f7d6548ebb35
And I ran "make install INSTALL=~/TeamCity/buildAgent/work/71b5f7d6548ebb35/install-win32/parallax" to create these files. they're huge!!! :O
The builds are huge! Any idea why the installation folder looks like this?
dzweb@davidzemonname:~/TeamCity/buildAgent/work/71b5f7d6548ebb35/install-win32/parallax/libexec/gcc/propeller-elf/5.0.0$ ls -alh
total 717M
drwxr-xr-x 4 dzweb psacln 4.0K Mar 31 20:29 .
drwxr-xr-x 3 dzweb psacln 4.0K Mar 31 20:29 ..
drwxr-xr-x 2 dzweb psacln 4.0K Mar 31 20:29 install-tools
drwxr-xr-x 2 dzweb psacln 4.0K Mar 31 20:29 plugin
-rwxr-xr-x 1 dzweb psacln 140M Mar 31 20:29 cc1
-rwxr-xr-x 1 dzweb psacln 143M Mar 31 20:29 cc1obj
-rwxr-xr-x 1 dzweb psacln 162M Mar 31 20:29 cc1plus
-rwxr-xr-x 1 dzweb psacln 2.2M Mar 31 20:29 collect2
-rwxr-xr-x 1 dzweb psacln 139M Mar 31 20:29 f951
-rwxr-xr-x 1 dzweb psacln 1.1K Mar 31 20:29 liblto_plugin.la
lrwxrwxrwx 1 dzweb psacln 22 Mar 31 20:29 liblto_plugin.so -> liblto_plugin.so.0.0.0
lrwxrwxrwx 1 dzweb psacln 22 Mar 31 20:29 liblto_plugin.so.0 -> liblto_plugin.so.0.0.0
-rwxr-xr-x 1 dzweb psacln 335K Mar 31 20:29 liblto_plugin.so.0.0.0
-rwxr-xr-x 1 dzweb psacln 130M Mar 31 20:29 lto1
-rwxr-xr-x 1 dzweb psacln 2.5M Mar 31 20:29 lto-wrapper
The source directory is ~/TeamCity/buildAgent/work/71b5f7d6548ebb35
And I ran "make install INSTALL=~/TeamCity/buildAgent/work/71b5f7d6548ebb35/install-win32/parallax" to create these files. they're huge!!! :O
LTO = link time optimization
This is a new feature of GCC that Eric is working on adding to PropGCC. I don't think it's quite debugged yet and is probably disabled in the propeller-gcc build.
I've deleted the old PropGCC project and renamed PropGCC5 to PropGCC. It's pretty obvious now - there's only two projects on the server: PropWare and PropGCC. PropGCC now has 6 build configurations, 2 versions of GCC * 3 OS builds. rpi still not working.
I've deleted the old PropGCC project and renamed PropGCC5 to PropGCC. It's pretty obvious now - there's only two projects on the server: PropWare and PropGCC. PropGCC now has 6 build configurations, 2 versions of GCC * 3 OS builds. rpi still not working.
I tried building on a Pi 2 on Monday which failed. Sadly don't recall if I got the same error as shown in post #132. Building from the older GCC in your original github repo was fine. I won't be able to try again until tomorrow.
Duh! As Heater pointed out, you've already said what went wrong in message #132. I'll try the cross build later tonight if I can recall what is necessary to setup for a RaspberryPi build.
I tried building on a Pi 2 on Monday which failed. Sadly don't recall if I got the same error as shown in post #132. Building from the older GCC in your original github repo was fine. I won't be able to try again until tomorrow.
The main difference between the propgcc github repository and the propeller-gcc one is that the propeller-gcc repository uses a new version of binutils and a new version of the library. By default, it uses the same version of gcc as the propgcc repository.
All cross builds (gcc 4 and 5) use gcc5's linux build. If the "-mp2" is a gcc4 only option, that would explain why it's failing when cross compiling gcc4 for windows. I'll mess with the configurations tonight to fix this issue.
All cross builds (gcc 4 and 5) use gcc5's linux build. If the "-mp2" is a gcc4 only option, that would explain why it's failing when cross compiling gcc4 for windows. I'll mess with the configurations tonight to fix this issue.
Okay, something is very wrong. When doing a build with gcc4, there shouldn't be any gcc5 compiler built and it certainly shouldn't be trying to use a gcc5 compiler.
Okay, something is very wrong. When doing a build with gcc4, there shouldn't be any gcc5 compiler built and it certainly shouldn't be trying to use a gcc5 compiler.
I meant to say it's a problem with my configuration. Cross-compiling requires propeller-elf-gcc to exist on the PATH... well, the version on my server's PATH is GCC5. So, I have to reconfigure the jobs and environment to do the right thing, not the easy thing.
I meant to say it's a problem with my configuration. Cross-compiling requires propeller-elf-gcc to exist on the PATH... well, the version on my server's PATH is GCC5. So, I have to reconfigure the jobs and environment to do the right thing, not the easy thing.
I thought my makefile pushed the build directory onto the front of PATH before invoking the individual component makefiles. That should override anything already in your path.
I've deleted the old PropGCC project and renamed PropGCC5 to PropGCC. It's pretty obvious now - there's only two projects on the server: PropWare and PropGCC. PropGCC now has 6 build configurations, 2 versions of GCC * 3 OS builds. rpi still not working.
Okay, I'm a bit confused I think. Are you now building everything from the propeller-gcc repository? Are you doing a cross build for Windows? I'm asking because i'm just working on modifying the openspin Makefile to do cross builds and am wondering how you managed to do them without these modifications. Or do you have a way to do native Windows, Mac, and Linux builds so that RaspberryPi is the only cross build?
Okay, I'm a bit confused I think. Are you now building everything from the propeller-gcc repository? Are you doing a cross build for Windows? I'm asking because i'm just working on modifying the openspin Makefile to do cross builds and am wondering how you managed to do them without these modifications. Or do you have a way to do native Windows, Mac, and Linux builds so that RaspberryPi is the only cross build?
I was actually wondering the very same thing... I'm not doing anything that weird/cool. I am using the new propeller-gcc repo and the host machine is Ubuntu 14.04. Btw - I sent you log in credentials a while ago via a PM if you want to check out the configurations for yourself. Once logged in (not as a guest) you can even see the environment variables at the time of each build and the full log.
Okay - fixed the path problem. Now the gcc4 win32 build is failing as expected, complaining about openspin.exe. I also found out that I'd forgotten to define the CROSS variable for gcc5 win32 build configuration, hence forth why it was "successful" :P
Next time you commit to propeller-gcc, all six build configurations will get kicked off. The Linux builds for gcc 4 & 5 will both be triggered in parallel and when each of those successfully finish, their respective cross builds will trigger.
I've disabled the explicit build step that ran "git submodule update". I'm fairly sure TeamCity does that by default, but am not sure yet. If the next build doesn't appear to pull your changes, I'll put it back in.
Okay - fixed the path problem. Now the gcc4 win32 build is failing as expected, complaining about openspin.exe. I also found out that I'd forgotten to define the CROSS variable for gcc5 win32 build configuration, hence forth why it was "successful" :P
Next time you commit to propeller-gcc, all six build configurations will get kicked off. The Linux builds for gcc 4 & 5 will both be triggered in parallel and when each of those successfully finish, their respective cross builds will trigger.
I've disabled the explicit build step that ran "git submodule update". I'm fairly sure TeamCity does that by default, but am not sure yet. If the next build doesn't appear to pull your changes, I'll put it back in.
Okay, I made some changes to the openspin Makefiles and submitted a pull request to Roy. Once those changes are merged, I hope the issue with openspin.exe will be resolved. What did you have to do to fix the path problem? I guess pushing the build directory onto the front of PATH wasn't enough? Is there something I need to change in my Makefile?
What did you have to do to fix the path problem? I guess pushing the build directory onto the front of PATH wasn't enough? Is there something I need to change in my Makefile?
At the end of gcc5 linux build, I execute "make INSTALL=$HOME/propgcc5-bin install". Completion of gcc5-linux triggers gcc5 win32 and gcc5 rpi. Then, in win32& rpi builds, I modify the PATH var as PATH=$HOME/propgcc5-bin/bin:$PATH. The same thing for gcc4, but with propgcc4-bin instead of propgcc5-bin.
Do the cross-compilation builds compile both a native and a cross version of the propgcc compiler??? I didn't think they would, which is why it made sense to me that you needed an existing, native version of propgcc on the path to be able to cross compile.
At the end of gcc5 linux build, I execute "make INSTALL=$HOME/propgcc5-bin install". Completion of gcc5-linux triggers gcc5 win32 and gcc5 rpi. Then, in win32& rpi builds, I modify the PATH var as PATH=$HOME/propgcc5-bin/bin:$PATH. The same thing for gcc4, but with propgcc4-bin instead of propgcc5-bin.
Do the cross-compilation builds compile both a native and a cross version of the propgcc compiler??? I didn't think they would, which is why it made sense to me that you needed an existing, native version of propgcc on the path to be able to cross compile.
I'm afraid I don't know the answer to that question. Eric added the cross compilation support. I'll try to find out how it is handled.
Do the cross-compilation builds compile both a native and a cross version of the propgcc compiler??? I didn't think they would, which is why it made sense to me that you needed an existing, native version of propgcc on the path to be able to cross compile.
No. IIRC you have to do a native build before doing a cross build.
No. IIRC you have to do a native build before doing a cross build.
Okay, I guess I have to revisit my scheme of pushing the build directory on the front of PATH since it will contain binaries for the target architecture not the build machine architecture.
Comments
Nothing. I just had to talk with my dad about security. Problem solved now.
You can visit TeamCity directly now (click "Login as guest") and download builds from there. If you click on a specific run configuration, you can download past builds as well. Each build tells you exactly what commits were incorporated into that build, so it becomes very obvious what you're downloading. You can also preview the contents of the archive prior to downloading.
http://david.zemon.name:8111/project.html?projectId=PropGCC5&tab=projectOverview
"PropGCC" is the old propgcc repo. "PropGCC5" is the new propeller-gcc repo. I will delete the "PropGCC" project as soon as I iron out a few more issues with PropGCC5 and then rename PropGCC5 to PropGCC (I created PropGCC5 before you added gcc4 as another submodule).
The source directory is ~/TeamCity/buildAgent/work/71b5f7d6548ebb35
And I ran "make install INSTALL=~/TeamCity/buildAgent/work/71b5f7d6548ebb35/install-win32/parallax" to create these files. they're huge!!! :O
This is a new feature of GCC that Eric is working on adding to PropGCC. I don't think it's quite debugged yet and is probably disabled in the propeller-gcc build.
Starting gcc4 builds now...
All cross builds (gcc 4 and 5) use gcc5's linux build. If the "-mp2" is a gcc4 only option, that would explain why it's failing when cross compiling gcc4 for windows. I'll mess with the configurations tonight to fix this issue.
I meant to say it's a problem with my configuration. Cross-compiling requires propeller-elf-gcc to exist on the PATH... well, the version on my server's PATH is GCC5. So, I have to reconfigure the jobs and environment to do the right thing, not the easy thing.
I was actually wondering the very same thing... I'm not doing anything that weird/cool. I am using the new propeller-gcc repo and the host machine is Ubuntu 14.04. Btw - I sent you log in credentials a while ago via a PM if you want to check out the configurations for yourself. Once logged in (not as a guest) you can even see the environment variables at the time of each build and the full log.
Edit: Never mind. I found the PM.
Next time you commit to propeller-gcc, all six build configurations will get kicked off. The Linux builds for gcc 4 & 5 will both be triggered in parallel and when each of those successfully finish, their respective cross builds will trigger.
I've disabled the explicit build step that ran "git submodule update". I'm fairly sure TeamCity does that by default, but am not sure yet. If the next build doesn't appear to pull your changes, I'll put it back in.
At the end of gcc5 linux build, I execute "make INSTALL=$HOME/propgcc5-bin install". Completion of gcc5-linux triggers gcc5 win32 and gcc5 rpi. Then, in win32& rpi builds, I modify the PATH var as PATH=$HOME/propgcc5-bin/bin:$PATH. The same thing for gcc4, but with propgcc4-bin instead of propgcc5-bin.
Do the cross-compilation builds compile both a native and a cross version of the propgcc compiler??? I didn't think they would, which is why it made sense to me that you needed an existing, native version of propgcc on the path to be able to cross compile.
No. IIRC you have to do a native build before doing a cross build.