Open HelloGrayson opened 9 years ago
Possibly related to #51
This is interesting. If I build from source with make distclean && make
, luajit compiles just fine:
Scanning dependencies of target luajit
[ 60%] Creating directories for 'luajit'
[ 61%] Performing download step for 'luajit'
-- file: /Users/graysonkoonce/neovim/neovim/.deps/build/downloads/luajit/LuaJIT-2.0.4.tar.gz
-- downloading...
src='http://luajit.org/download/LuaJIT-2.0.4.tar.gz'
dst='/Users/graysonkoonce/neovim/neovim/.deps/build/downloads/luajit/LuaJIT-2.0.4.tar.gz'
timeout='none'
-- downloading... done
-- extracting...
src='/Users/graysonkoonce/neovim/neovim/.deps/build/downloads/luajit/LuaJIT-2.0.4.tar.gz'
dst='/Users/graysonkoonce/neovim/neovim/.deps/build/src/luajit'
-- extracting... [tar xfz]
-- extracting... [analysis]
-- extracting... [rename]
-- extracting... [clean up]
-- extracting... done
[ 63%] No patch step for 'luajit'
[ 64%] No update step for 'luajit'
[ 66%] No configure step for 'luajit'
[ 67%] No build step for 'luajit'
[ 69%] Performing install step for 'luajit'
==== Building LuaJIT 2.0.4 ====
HOSTCC host/minilua.o
HOSTLINK host/minilua
DYNASM host/buildvm_arch.h
HOSTCC host/buildvm.o
HOSTCC host/buildvm_asm.o
HOSTCC host/buildvm_peobj.o
HOSTCC host/buildvm_lib.o
HOSTCC host/buildvm_fold.o
HOSTLINK host/buildvm
BUILDVM lj_vm.s
ASM lj_vm.o
CC lj_gc.o
BUILDVM lj_ffdef.h
CC lj_err.o
CC lj_char.o
BUILDVM lj_bcdef.h
CC lj_bc.o
CC lj_obj.o
CC lj_str.o
CC lj_tab.o
CC lj_func.o
CC lj_udata.o
CC lj_meta.o
CC lj_debug.o
CC lj_state.o
CC lj_dispatch.o
CC lj_vmevent.o
CC lj_vmmath.o
CC lj_strscan.o
CC lj_api.o
CC lj_lex.o
CC lj_parse.o
CC lj_bcread.o
CC lj_bcwrite.o
CC lj_load.o
CC lj_ir.o
CC lj_opt_mem.o
BUILDVM lj_folddef.h
CC lj_opt_fold.o
CC lj_opt_narrow.o
CC lj_opt_dce.o
CC lj_opt_loop.o
CC lj_opt_split.o
CC lj_opt_sink.o
CC lj_mcode.o
CC lj_snap.o
CC lj_record.o
CC lj_crecord.o
BUILDVM lj_recdef.h
CC lj_ffrecord.o
CC lj_asm.o
CC lj_trace.o
CC lj_gdbjit.o
CC lj_ctype.o
CC lj_cdata.o
CC lj_cconv.o
CC lj_ccall.o
CC lj_ccallback.o
CC lj_carith.o
CC lj_clib.o
CC lj_cparse.o
CC lj_lib.o
CC lj_alloc.o
CC lib_aux.o
BUILDVM lj_libdef.h
CC lib_base.o
CC lib_math.o
CC lib_bit.o
CC lib_string.o
CC lib_table.o
CC lib_io.o
CC lib_os.o
CC lib_package.o
CC lib_debug.o
CC lib_jit.o
CC lib_ffi.o
CC lib_init.o
AR libluajit.a
CC luajit.o
BUILDVM jit/vmdef.lua
LINK luajit
OK Successfully built LuaJIT
==== Successfully built LuaJIT 2.0.4 ====
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:
Getting the same error. Any news on this?
— Reply to this email directly or view it on GitHub https://github.com/neovim/homebrew-neovim/issues/114#issuecomment-158808157 .
+1 running into the same issue.
:+1: 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:
brew install --verbose neovim
brew gist-logs neovim
If we can see the link line, then we can see which library is actually being picked up.
Here are my logs: https://gist.github.com/anonymous/acabb834f7de2a4c3a64
+1 ;)
What does your environments look like? Out machine running the OS X build is pretty pristine--here's the output of env | sort
(make sure you cut out anything that may expose sensitive information like tokens for GitHub, etc):
HOME=/Users/quickbuild
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
PWD=/Users/quickbuild
SHELL=/bin/bash
SHLVL=1
TERM=xterm-256color
USER=quickbuild
_=/usr/bin/env
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:
AUTOJUMP_ERROR_PATH=/Users/prashant/Library/autojump/errors.log
AUTOJUMP_SOURCED=1
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.58k0JjfIYT/Render
DISPLAY=/private/tmp/com.apple.launchd.sshW612dML/org.macosforge.xquartz:0
EDITOR=vim
GOPATH=/Users/prashant/gocode
HOME=/Users/prashant
ITERM_PROFILE=Prashant
ITERM_SESSION_ID=w1t0p0
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LESS=-R
LOGNAME=prashant
LSCOLORS=Gxfxcxdxbxegedabagacad
MANPATH=/Users/prashant/.nvm/v0.10.32/share/man:/usr/local/share/man:/usr/share/man:/opt/X11/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man
NVM_BIN=/Users/prashant/.nvm/v0.10.32/bin
NVM_DIR=/Users/prashant/.nvm
NVM_IOJS_ORG_MIRROR=https://iojs.org/dist
NVM_NODEJS_ORG_MIRROR=https://nodejs.org/dist
NVM_PATH=/Users/prashant/.nvm/v0.10.32/lib/node
OLDPWD=/Users/prashant
PAGER=less
PATH=/Users/prashant/.dnx/runtimes/dnx-mono.1.0.0-beta7/bin:/Users/prashant/.dnx/bin:/Users/prashant/.nvm/v0.10.32/bin:/usr/local/sbin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/go/bin:/Users/prashant/bin:/Users/prashant/gocode/bin
PWD=/Users/prashant
SHELL=/usr/local/bin/zsh
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.slYQn67gGq/Listeners
TERM=xterm-256color
TERM_PROGRAM=iTerm.app
TMPDIR=/var/folders/hs/w2ggc5kx7f77qfb7j_1h54kh0000gn/T/
USER=prashant
VIRTUALENVWRAPPER_HOOK_DIR=/Users/prashant/.virtualenvs
VIRTUALENVWRAPPER_PROJECT_FILENAME=.project
VIRTUALENVWRAPPER_SCRIPT=/usr/local/bin/virtualenvwrapper.sh
VIRTUALENVWRAPPER_WORKON_CD=1
VISUAL=vim
WORKON_HOME=/Users/prashant/.virtualenvs
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
_=/usr/bin/env
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
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.
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.eH3LnuQopO/Render
COLORFGBG=7;0
COMMAND_MODE=unix2003
CVS_RSH=/usr/bin/ssh
DISPLAY=/private/tmp/com.apple.launchd.eqVtsIuvOD/org.macosforge.xquartz:0
EDITOR=/Users/benfleis/bin/nvim
EVENT_NOKQUEUE=1
GOPATH=/Users/benfleis/go
GOROOT=/usr/local/Cellar/go/1.5.1/libexec
HISTSIZE=10000
HOME=/Users/benfleis
ITERM_PROFILE=Default
ITERM_SESSION_ID=w0t0p0
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LC_CTYPE=UTF-8
LESS=-iFMRX
LOGNAME=benfleis
MANPATH=/Users/benfleis/.nvm/v0.10.32/share/man:/usr/share/man:/usr/local/share/man:/opt/X11/share/man:/usr/X11R6/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man
NVM_BIN=/Users/benfleis/.nvm/v0.10.32/bin
NVM_DIR=/Users/benfleis/.nvm
NVM_IOJS_ORG_MIRROR=https://iojs.org/dist
NVM_NODEJS_ORG_MIRROR=https://nodejs.org/dist
NVM_PATH=/Users/benfleis/.nvm/v0.10.32/lib/node
OLDPWD=/Users/benfleis/go/src/github.com/uber/ringpop-go
PAGER=/usr/bin/less
PATH=/Users/benfleis/neovim/bin:/Users/benfleis/.nvm/v0.10.32/bin:/Users/benfleis/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
PROMPT=[%(?.$PR_LIGHT_GREEN%m.$PR_RED%m)$PR_NO_COLOUR] $PR_LIGHT_GREEN%~$PR_NO_COLOUR $
PWD=/tmp
PYTHONPATH=/usr/local/lib/python2.7/site-packages
RSYNC_RSH=/usr/bin/ssh
SECURITYSESSIONID=186a5
SHELL=/bin/zsh
SHLVL=2
SSH_AUTH_SOCK=/tmp/ssh-benfleis/agent
TERM=screen-256color
TERM_PROGRAM=iTerm.app
TMPDIR=/var/folders/h1/jm5lm7gd3fg8m72tktqb0rgr0000gq/T/
TMUX=/private/var/folders/h1/jm5lm7gd3fg8m72tktqb0rgr0000gq/T/tmux-503/default,9696,2
TMUX_PANE=%26
UBER_HOME=/Users/benfleis/Uber
UBER_OWNER=benfleis@uber.com
USER=benfleis
USERXSESSIONRC=/Users/benfleis/.xsession
VAGRANT_DEFAULT_PROVIDER=aws
VIRTUALENVWRAPPER_HOOK_DIR=/Users/benfleis/.virtualenvs
VIRTUALENVWRAPPER_PROJECT_FILENAME=.project
VIRTUALENVWRAPPER_SCRIPT=/usr/local/bin/virtualenvwrapper.sh
VIRTUALENVWRAPPER_WORKON_CD=1
VISUAL=/Users/benfleis/bin/nvim
WORKON_HOME=/Users/benfleis/.virtualenvs
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
_=/usr/bin/env
_SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.HBAVkOWqhx/Listeners
__CF_USER_TEXT_ENCODING=0x1F7:0x0:0x0
_compdir=/Users/benfleis/.zsh/completion
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 and build from source which works fine. I mean at some point to start trying to bisect between how the recipe does the build and just a straight up make. On Sun, Jan 10, 2016 at 12:55 benfleis notifications@github.com wrote:
FTR, works like a charm from my personal box, which is El Capitan. Are any of you running El Cap, or still 10.10?
— Reply to this email directly or view it on GitHub https://github.com/neovim/homebrew-neovim/issues/114#issuecomment-170393137 .
I mean at some point to start trying to bisect between how the recipe does the build and just a straight up make.
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:
:: find -x / -name '*unwind.dylib*' 2>/dev/null
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/usr/lib/system/libunwind.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/system/libunwind.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator.sdk/usr/lib/system/libunwind.dylib
/Users/jszakmeister/Library/Developer/Xcode/iOS DeviceSupport/7.1.2 (11D257)/Symbols/usr/lib/system/libunwind.dylib
/usr/lib/system/libunwind.dylib
Perhaps you have a stray version being included instead? Or the wrong clang compiler is being picked up? It looks /usr/local/Library/ENV/4.3/cc
is a Homebrew script that does a fair amount of stuff, so perhaps it's doing something unexpected in your situation? This would be one spot where the builds are different, since our normal (outside of Homebrew build) doesn't use Homebrew's build chain. Perhaps @xu-cheng might have some insights here?
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:
brew install neovim --env=std
And see if it builds?
It looks like setting env
to std
helps, I was able to get neovim successfully built.
Here are gist-logs, https://gist.github.com/fadbef18771582062861
(compared to my previously failing build: https://gist.github.com/acabb834f7de2a4c3a64)
Thanks for the tip @DomT4
Had the same issue when upgrading to v0.2.0
, using --env=std
works in that scenario as well:
brew upgrade neovim --env=std
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