-
Notifications
You must be signed in to change notification settings - Fork 72
Installation failing on missing LuaJIT 2.0.4 symbols #114
Comments
Possibly related to #51 |
This is interesting. If I build from source with
|
I have seen the same thing when I try to install it on Mac OS 10.11.1 |
Are there any homebrew caches or similar that you can clean? |
I did clean the cach and built it again. The same linking error. |
Getting the same error. Any news on this? |
I ended up installing it from source. On Sunday, November 22, 2015, Ethan Veres notifications@github.com wrote:
|
+1 running into the same issue. |
👍 same here |
My guess is that you all have installed LuaJIT some other way, and it is getting picked up in the link step instead of our version. We place our dependencies at the front of the search list, but it's possible that another dependency is tweaking the library search patch and causing some other stray version to be picked up. One thing would actually help locate the problem is to try and build with the verbose option, and post your gist logs:
If we can see the link line, then we can see which library is actually being picked up. |
Here are my logs: |
+1 ;) |
What does your environments look like? Out machine running the OS X build is pretty pristine--here's the output of
From the logs, I can't see any reason why luajit would be built for the wrong architecture, so it leads me to believe there is something else affecting you all. |
Here is my environment:
I don't see anything in there that would change the environment it would build for. |
Mine looks similarly clean. @prashantv @breerly @jcorbin, Do we have something in common w/ our envs? I'm gonna try on my personal laptop shortly (updating XCode) to see if it fails there as well.
|
FTR, works like a charm from my personal box, which is El Capitan. Are any of you running El Cap, or still 10.10? |
I'm running El Capitan. Personally I've just given up on the brew recipe
|
I don't think it's so much how the build is conducted--it's not that different than the straight-up make, which does something very similar but less suited the brew's installation process. I think it has more to do with the environment that is being setup, or stray libraries being found instead of the ones we want. Looking at the errors again, it appears that perhaps an alternate version of libunwind is being picked up--one that doesn't support 64-bit. On my system, I see these versions:
Perhaps you have a stray version being included instead? Or the wrong clang compiler is being picked up? It looks |
Datapoint -- since original build fail, XCode updated, and upgraded to El Cap. Now it builds just fine. The build did include a rebuild of LuaJIT, among many other things. |
Sorry, I have no idea what's going on. cc @DomT4 who in my memory has more experience on lua staff. |
This is interesting. Can't reproduce locally but given how our environment is intended to work I suspect it's probably the guilty party in toying with some of these builds. I'm not recommending this as a permanent solution but can anyone having build trouble try:
And see if it builds? |
It looks like setting Here are gist-logs, (compared to my previously failing build: https://gist.github.com/acabb834f7de2a4c3a64) Thanks for the tip @DomT4 |
Had the same issue when upgrading to
|
Unable to install neovim 0.1.0 on OSX Yosemite
10.10.5
withxcode-select version 2339
by runningbrew install neovim
.Looks like it's choking on luajit:
Full logs: https://gist.github.com/anonymous/0b23efa4f12302a5fbff
The text was updated successfully, but these errors were encountered: