libuv has it's target_arch specified incorrectly
#8826
Comments
ghost
assigned 
|
@pnkfelix, I believe that https://gist.github.com/alexcrichton/6369271 will solve the problem, but can you confirm before I open a pull request? |
|
@alexcrichton Unfortunately the patch did not fix the problem for me. But you have now given me some places to look for a fix, so I'll see if I can find a fix myself. |
|
on a subsequent run (using |
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86 architecture and ia32 for a 32-bit architecture, so this performs the relevant mapping and then invokes libuv's configure script with the appropriate target architecture. This can be verified by running make with VERBOSE=1 and seeing that beforehand on a 64-bit build libuv was passed "-arch i386" and now it's passed "-arch x86_64" Closes #8826
|
The fix for this got reverted (accidentally?) by SHA 3c5a43e causing the bug to be re-injected. |
|
This is only a bug with our usage of gyp though, so is this still an issue? The libuv upgrade was reverted because it was the most likely suspect of a log of segfaults on the bots |
|
Well, it seemed like I was encountering the same problems in my builds tonight that had motivated this fix in the first place. But I also did not know what the reason was for SHA 3c5a43e ; if we are indeed not using gyp anymore (as implied by @alexcrichton 's note, then I'm not sure what is going on. I'll investigate more, and close this if I cannot confirm that it is a real problem more concretely. |
|
okay, never mind, the libuv is being built in x86_64 mode. Closing. |
|
(the aforementioned reversion was PR #8866) |
|
(the problem I was seeing was an artifact of #8865 ; sorry for the noise.) |
Right now when you're building a 64-bit build it may error because libuv is built as a 32-bit library. It looks like gyp doesn't understand
x86_64, but ratherx64cc @pnkfelix who was having problems with this.
The text was updated successfully, but these errors were encountered: