Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows installer and binaries #46

Open
tdaede opened this issue Jan 10, 2013 · 5 comments
Open

Windows installer and binaries #46

tdaede opened this issue Jan 10, 2013 · 5 comments

Comments

@tdaede
Copy link

tdaede commented Jan 10, 2013

Given that summon is basically the only toolchain compatible with libopencm3 hard float at the moment, it'd be nice to have a preferred Windows installation method / installer, a la devkitPro.

Questions to be answered:
Build the windows binaries with cygwin, mingw, or mingw-w64?
What build environment to use to build the binaries?

@esden
Copy link
Owner

esden commented Jan 10, 2013

Hi, Yes having binaries for all of the three big OS's would be nice. I don't use windows so it is difficult for me to answer this question. As far as I know mingw is the "lightest" solution but tends to have more issues then cygwin. But your milage may vary.

P.S. The best thing at the end would be automatic nightly builds upon new commits that upload the binaries to github for example. Any ideas on that too?

@tdaede
Copy link
Author

tdaede commented Jan 11, 2013

Good idea on the nightly builds. I think that automated builds for Linux would be a good first step. I have a slow VPS that I'd be willing to run nightly builds on. I'll see if I can get something set up.

I would much prefer that the binaries be built with mingw, as that means that they don't have any weird dependencies. However the build scripts have to support the build environment. The build environment could still be Linux - I could install mingw. On windows, either mingw/msys or Cygwin could be used - in fact, Cygwin's package manager is mingw-w64's main release channel.

@tdaede
Copy link
Author

tdaede commented Jan 12, 2013

I have a nightly build service here (actually it checks the repo daily and only does a build if there is a change)
http://rei.thomasdaede.com:8080/job/summon-arm-toolchain/
Worryingly, from removing all the build stamps, I had to run the build twice to get it to actually complete. I need to see if that's a script bug or some problem on my end.

The binaries are dynamically linked for rhel6 right now, so they may or may not work on your system.

Windows builds via mingw32 are a bit farther away. I want to add mpfr, mpc, and gmp building functionality to summon-arm-toolchain first.

@esden
Copy link
Owner

esden commented Jan 22, 2013

yes I see the problem too with linaro gcc having a problem (with no apparent error) where you have to run the sat script twice. I assume it may be related to the parallel build (-j parameter)

@Clouded
Copy link

Clouded commented Mar 31, 2013

I've managed to build SAT on Windows with GCC 4.8.0 and newlib-nano under msys with MinGW 4.8.0. I did this by stripping down the SAT script, of course it would be better to just modify the normal version where needed, but I had no time to test all the sections as they require more additional tools. I've uploaded pre-built binaries of Summon ARM Toolchain 4.8.0 for Windows on Bintray - http://dl.bintray.com/content/clouded/Summon-ARM-Toolchain-for-Windows
Modified version of the script is available in the forked repo https://github.com/Clouded/summon-arm-toolchain
Updated patches for GCC 4.8.0 are also available there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants