Repository navigation
libuv has it's target_arch specified incorrectly #8826
Description
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 rather x64
cc @pnkfelix who was having problems with this.
Metadata
Metadata
Assignees
Labels
No labels
Activity
alexcrichton commentedon Aug 28, 2013
@pnkfelix, I believe that https://gist.github.com/alexcrichton/6369271 will solve the problem, but can you confirm before I open a pull request?
pnkfelix commentedon Aug 28, 2013
@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.
pnkfelix commentedon Aug 28, 2013
on a subsequent run (using
-j1), it seems like the patch does work. I'm not sure why my earlier run did not work. Maybe there is interference when building with-jNforN > 1?)Fix compilation issues with libuv on OSX
auto merge of #8832 : alexcrichton/rust/fix-libuv-build, r=pcwalton
pnkfelix commentedon Aug 31, 2013
The fix for this got reverted (accidentally?) by SHA 3c5a43e causing the bug to be re-injected.
alexcrichton commentedon Aug 31, 2013
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
pnkfelix commentedon Aug 31, 2013
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.
pnkfelix commentedon Aug 31, 2013
okay, never mind, the libuv is being built in x86_64 mode. Closing.
pnkfelix commentedon Aug 31, 2013
(the aforementioned reversion was PR #8866)
pnkfelix commentedon Aug 31, 2013
(the problem I was seeing was an artifact of #8865 ; sorry for the noise.)