neovim / homebrew-neovim

Homebrew formula
MIT License
402 stars 72 forks source link

Installation failing on missing LuaJIT 2.0.4 symbols #114

Open HelloGrayson opened 9 years ago

HelloGrayson commented 9 years ago

Unable to install neovim 0.1.0 on OSX Yosemite 10.10.5 with xcode-select version 2339 by running brew install neovim.

Looks like it's choking on luajit:

Undefined symbols for architecture x86_64:
  "__Unwind_DeleteException", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
  "__Unwind_GetCFA", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
  "__Unwind_RaiseException", referenced from:
      _lj_err_throw in libluajit.a(lj_err.o)
  "__Unwind_SetGR", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
  "__Unwind_SetIP", referenced from:
      _lj_err_unwind_dwarf in libluajit.a(lj_err.o)
ld: symbol(s) not found for architecture x86_64

Full logs: https://gist.github.com/anonymous/0b23efa4f12302a5fbff

HelloGrayson commented 9 years ago

Possibly related to #51

HelloGrayson commented 9 years ago

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 ====
ethankao commented 9 years ago

I have seen the same thing when I try to install it on Mac OS 10.11.1

fwalch commented 9 years ago

Are there any homebrew caches or similar that you can clean?

ethankao commented 9 years ago

I did clean the cach and built it again. The same linking error.

ethanve commented 8 years ago

Getting the same error. Any news on this?

ethankao commented 8 years ago

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 .

prashantv commented 8 years ago

+1 running into the same issue.

jcorbin commented 8 years ago

:+1: same here

jszakmeister commented 8 years ago

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.

prashantv commented 8 years ago

Here are my logs: https://gist.github.com/anonymous/acabb834f7de2a4c3a64

benfleis commented 8 years ago

+1 ;)

benfleis commented 8 years ago

More logs: https://gist.github.com/anonymous/bf9be558145ad6bf2c9b#file-02-make-L1099

jszakmeister commented 8 years ago

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.

prashantv commented 8 years ago

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.

benfleis commented 8 years ago

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
benfleis commented 8 years ago

FTR, works like a charm from my personal box, which is El Capitan. Are any of you running El Cap, or still 10.10?

jcorbin commented 8 years ago

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 .

jszakmeister commented 8 years ago

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?

benfleis commented 8 years ago

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.

xu-cheng commented 8 years ago

Sorry, I have no idea what's going on. cc @DomT4 who in my memory has more experience on lua staff.

DomT4 commented 8 years ago

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?

prashantv commented 8 years ago

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

HelloGrayson commented 7 years ago

Had the same issue when upgrading to v0.2.0, using --env=std works in that scenario as well:

brew upgrade neovim --env=std