Fail to compile due to incorrect LDFLAGS (Mac OS X 10.13.1 High Sierra)

[stephenmckinney]

Following the install instructions, I execute:

cd ruby/command-t/ext/command-t
ruby extconf.rb
make

And get the following error:

linking shared-object ext.bundle
ld: warning: directory not found for option '-L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/libressl/lib'
ld: warning: directory not found for option '-L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/lib'
ld: warning: directory not found for option '-L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/libressl/lib'
ld: warning: directory not found for option '-L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/lib'

These directories are set in ldflags. Makefile and output are in this gist:
https://gist.github.com/stephenmckinney/0973368cb0385e5d3a1775df4ffb9e31

[wincent]

No idea why it's trying to pull in those directories (doesn't repro for me on High Sierra, although I am using Homebrew-installed Ruby so my Makefile ends up looking like this). Don't see any reason why it would have interest in something marked "internal", and especially nothing to do with libressl.

What happens if you edit the Makefile to remove the dodgy references?

[ryanblakeley]

I got the same error. I removed those references and the next make looks like it passed.

Makefile line 88 before:

ldflags  = -L.             -L -L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/lib

line 88 after:

ldflags  = -L.

> make
linking shared-object ext.bundle

[markwu]

I can confirmed this bug, and delete those LDFLAGS references, command-t build correct. I use RVM ruby.

My system is osx 10.13.3
Homebrew version is 1.5.5-16-g9225dac
RVM version is 1.29.3
RVM ruby is ruby 2.5.0p0
System Ruby is 2.3.3p222

ldflags  = -L.             -L /BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/libressl/lib -L/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/lib

I build command-t with the following steps:

1. rvm use system
2. ruby extconf.rb
3. make

[skarger]

I had a similar problem using system ruby (2.3.3) on macOS High Sierra 10.13.3.

I noticed the ld warnings about /BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.Internal.sdk/usr/local/libressl/lib' when running make for Vim itself, as well as for command-t.

Ultimately I worked around it by installing Ruby with Homebrew and then recompiling Vim and command-t.

I installed Vim from source and had initially configured it like so with the system ruby:

cd vim
./configure --prefix=/usr/local \
            --with-features=huge \
            --enable-multibyte \
            --enable-rubyinterp \
            --with-ruby-command=/usr/bin/ruby \
            --enable-pythoninterp \
            --enable-python3interp

As an intermediate try I compiled Vim with the --with-ruby-command option pointing at one of my rbenv rubies. For whatever reason, in that case vim would crash and exit when I tried to use command-t.

Then I installed Ruby with Homebrew ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17], and adjusted my Vim compilation to use it (below). I also had to run make distclean to clear the cached Ruby headers before re-running configure. Then ran make; make install for Vim, and finally rebuilt command-t as described in the docs. It's working.

./configure --prefix=/usr/local \
            --with-features=huge \
            --enable-multibyte \
            --enable-rubyinterp \
            --with-ruby-command=/usr/local/bin/ruby \
            --enable-pythoninterp \
            --enable-python3interp

I'm still not sure why the loader flags had that MacOSX10.13.Internal.sdk library directory could not be found. Evidently it had something to do with the system ruby that comes with High Sierra. That said, on my work machine I also have High Sierra and had successfully compiled Vim and command-t using the system ruby several months ago.

[wincent]

Given the big rewrite for v6.0.x, I'm closing all older issues as there is unlikely to be anything significant happening on the 5-x-devel branch from here on¹. Feedback issue for 6.0.x is here:

• 🆕 Command-T 6.0.0 release — compendium issue #393

Footnotes

1. Patches and PRs would be welcome, but my personal efforts are going to be directed towards main. ↩