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 system image error with libuv 0.11.22 update #6314

Closed
tkelman opened this issue Mar 30, 2014 · 4 comments
Closed

Windows system image error with libuv 0.11.22 update #6314

tkelman opened this issue Mar 30, 2014 · 4 comments

Comments

@tkelman
Copy link
Contributor

tkelman commented Mar 30, 2014

As mentioned here 1aed903#commitcomment-5844801 this latest libuv update is causing trouble, both locally and on AppVeyor. Was initially getting an ERROR: could not open file c:\projects\julia\base during building the system image.

This commit 368a537 resulted in the error message dropping the "could not open file" part, just an empty ERROR: with no message. Here's as much as I could get out of gdb: https://gist.github.com/tkelman/9871004

@tkelman
Copy link
Contributor Author

tkelman commented Mar 31, 2014

Thanks, this fixed it locally. Not on AppVeyor though, something about make[1]: *** [/c/projects/julia/usr/lib/julia/sys0.o] Error 116. No idea what that is, maybe it'll magically start working again in a few days with updated binaries.

@ihnorton
Copy link
Member

The latest binaries are on 4e19b59 so should include this (build failed earlier and was only successful after this).

@tkelman
Copy link
Contributor Author

tkelman commented Mar 31, 2014

Hm, I don't know what's up then. If I fall back to building debug then it's at least able to build the system image, but it's hanging in the core unit tests.

Have a theory, testing now. It may be that MSYS1 is broken by the terminal handling changes, and now only MSYS2 and Cygwin work.

@tkelman
Copy link
Contributor Author

tkelman commented Apr 1, 2014

Nope, unrelated to terminal handling or anything Julia-side. Turns out AppVeyor went and installed MinGW by default, which is a nice gesture to cross-platform projects like us, but they installed a version that isn't compatible with the cross-compiled Windows binaries (as I struggled with for a while - the mingw-builds version we recommend for from-scratch MSYS2 builds is not compatible either). I should've paid closer attention to the early part of the logs, my build script is set up not to download MinGW if gcc is already on the path. Removing the incompatible pre-installed one from the path in AppVeyor before running the script did the trick.

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

2 participants