Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

weechat 1.4 --with-ruby did not build #117

Closed
manavortex opened this issue Apr 7, 2016 · 33 comments
Closed

weechat 1.4 --with-ruby did not build #117

manavortex opened this issue Apr 7, 2016 · 33 comments
Labels
upstream issue An upstream issue report is needed user configuration User configuration rather than a Homebrew issue

Comments

@manavortex
Copy link

Fix that worked

mkdir ~/Documents/fink-2016-04-11
sudo mv /sw ~/Documents/fink-2016-04-11
brew reinstall --with-ruby weechat

Dirty fix that also worked

cd /Library/Caches/Homebrew
tar -zxvf weechat-1.4.tar.gz
locate ruby.h
nano weechat-1.4/src/plugins/ruby/CMakeLists.txt
added path where ruby.h lived via include_directories($path) after if(RUBY_FOUND)
tar -zcvf weechat-1.4.tar.gz weechat-1.4
try reinstalling, insert "actual" checksum with brew edit weechat
tried again reinstalling, same game for the next error...
rinse and repeat until compiles

  • Ran brew update and retried your prior step?
  • Ran brew doctor, fixed as many issues as possible and retried your prior step?

    Your system is ready to brew.

Bug reports:

Weechat with Ruby fails to build:

$ brew reinstall weechat --with-ruby
==> Reinstalling weechat with --with-aspell, --with-curl, --with-python, --with-perl, --with-ruby

Scanning dependencies of target ruby
[ 48%] Building C object src/plugins/ruby/CMakeFiles/ruby.dir/weechat-ruby.o
[ 50%] Building C object src/plugins/python/CMakeFiles/python.dir/weechat-python-api.o
[ 50%] Building C object src/plugins/irc/CMakeFiles/irc.dir/irc-input.o
/tmp/weechat20160407-18613-1k9c3l5/weechat-1.4/src/plugins/ruby/weechat-ruby.c:25:10: fatal error: **'ruby.h' file not found**
**#include <ruby.h>**
         ^
1 error generated.
make[2]: *** [src/plugins/ruby/CMakeFiles/ruby.dir/weechat-ruby.o] Error 1
make[1]: *** [src/plugins/ruby/CMakeFiles/ruby.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
...
make: *** [all] Error 2

brew gist-logs weechat

#1: https://gist.github.com/anonymous/5caa7b6985d674e6b398e74567b2c69f
#2: https://gist.github.com/anonymous/6f0c14238ec2a3a866312c4ba51ba9ad
#3 https://gist.github.com/anonymous/fe427768d84d0c95facdfe33cb48b53a
#4

Attempted solutions (chronological order):

  • brew reinstall aspell && brew link aspell --force
  • trying to recompile aspell-0.60.6.1 from source, failed due to a bunch of errors like
error: redeclaration of 'aerror_other' with a different type: 'const
      acommon::ErrorInfo *const' vs 'const struct AspellErrorInfo *const'

Formula Requests:

My OCD would appreciate a fix for

**
Make Warning:

  Manually-specified variables were not used by the project:

    CMAKE_CXX_FLAGS_RELEASE
@ilovezfs ilovezfs added the user configuration User configuration rather than a Homebrew issue label Apr 8, 2016
@ilovezfs
Copy link
Contributor

ilovezfs commented Apr 8, 2016

Both aspell and weechat compile fine, and I cannot reproduce this issue. The problem seems to be that it cannot find your ruby, which probably has something to do with how you're using rbenv.

You can try moving your bash profile out of the way. Then check if the issue persists at that point.

mv ~/.bash_profile ~/bash_profile

Some notes about other things you mentioned:

emacs is not needed and has nothing to do with this issue.

gperftools is not needed and has nothing to do with this issue. You can brew uninstall it.

brew install ncurses && brew link ncurses --force
You should not do that. Those are :keg_only for good reason. You should brew unlink them.

export PATH="/Users/manavortex/.rbenv/versions/2.2.3/include/ruby-2.2.0/ruby:$PATH"
This is a misunderstanding of the PATH environment variable, which is the set of paths to programs you can run in the terminal with using an absolute path. It doesn't have anything to do with header files.

CMAKE_CXX_FLAGS_RELEASE is put in automatically as one of the std_cmake_args and there's no reason to remove it just because it's unused.

@manavortex
Copy link
Author

Hi there,
I've been at this two evenings before I started documenting what I did, so my solutions were pretty esoteric at that point. I kinda forgot to mention that, sorry.

By now I have fixed the issue - I do imagine to believe that I posted this, but for some reason I haven't. Basically, I've manually put the links to the missing ruby files into the archive's make file, re-zipped it, brew edit weechat-ed and brewed with my own archive.

You should not do that. Those are :keg_only for good reason. You should brew unlink them
Yeah, did that later. :)

export PATH="/Users/manavortex/.rbenv/versions/2.2.3/include/ruby-2.2.0/ruby:$PATH"
This is a misunderstanding of the PATH environment variable, which is the set of paths to programs you can run in the terminal with using an absolute path. It doesn't have anything to do with header files.
True, but I had hoped that by adding it to the path the header files would pick up the hint. As I said, I was pretty desperate at that point. :D

CMAKE_CXX_FLAGS_RELEASE is put in automatically as one of the std_cmake_args and there's no reason to remove it just because it's unused.

As I said - for the sake of OCD. :)

Moving my .bash_profile out of the way didn't solve it either:
https://gist.github.com/anonymous/791249e0cdf14eed1d47a27bbefebf9c
(Yes, I did start a new session :D)

@ilovezfs
Copy link
Contributor

ilovezfs commented Apr 8, 2016

Moving my .bash_profile out of the way didn't solve it either:

You should try with a new user.

@manavortex
Copy link
Author

@ilovezfs
Copy link
Contributor

ilovezfs commented Apr 8, 2016

@manavortex OK, try with an empty brew installation, then.

mkdir ~/Documents/homebrew-2016-04-08
sudo mv /usr/local ~/Documents/homebrew-2016-04-08
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
 brew install --with-aspell --with-curl --with-python --with-perl --with-ruby weechat

@DomT4
Copy link
Member

DomT4 commented Apr 9, 2016

I wonder if superenv may be being a little overzealous in refurbishing.

OP's logs reference pretty consistently this sort of thing during make:

clang called with: -DENABLE_NLS -DHAVE_CONFIG_H -DHAVE_GCRYPT -DHAVE_GNUTLS -DHAVE_ICONV -DHAVE_ZLIB -DWEECHAT_LICENSE="GPL3" -DWEECHAT_VERSION="1.4" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_LARGE_FILES -Druby_EXPORTS -I/usr/local/include -I/tmp/weechat20160407-18613-1k9c3l5/weechat-1.4/build -I/sw/include/ruby-2.0 -I/sw/include/ruby-2.0/x86_64-darwin -Wall -Wextra -Werror-implicit-function-declaration -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11 -fPIC -fPIC -fPIC -o CMakeFiles/ruby.dir/weechat-ruby.o -c /tmp/weechat20160407-18613-1k9c3l5/weechat-1.4/src/plugins/ruby/weechat-ruby.c
superenv removed:  -I/usr/local/include -I/sw/include/ruby-2.0 -I/sw/include/ruby-2.0/x86_64-darwin -Wall -Wextra -Werror-implicit-function-declaration -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
superenv added:    -pipe -w -Os -march=native -isystem/usr/local/include -isystem/usr/include/libxml2 -isystem/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/gettext/include -I/usr/local/opt/curl/include
superenv executed: clang -pipe -w -Os -march=native -DENABLE_NLS -DHAVE_CONFIG_H -DHAVE_GCRYPT -DHAVE_GNUTLS -DHAVE_ICONV -DHAVE_ZLIB -DWEECHAT_LICENSE="GPL3" -DWEECHAT_VERSION="1.4" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_LARGE_FILES -Druby_EXPORTS -I/tmp/weechat20160407-18613-1k9c3l5/weechat-1.4/build -DNDEBUG -mmacosx-version-min=10.11 -fPIC -fPIC -fPIC -o CMakeFiles/ruby.dir/weechat-ruby.o -c /tmp/weechat20160407-18613-1k9c3l5/weechat-1.4/src/plugins/ruby/weechat-ruby.c -isystem/usr/local/include -isystem/usr/include/libxml2 -isystem/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/gettext/include -I/usr/local/opt/curl/include

Where the two Ruby header references are tossed, but none are re-added. That could explain why build goes from being able to find it to suddenly ruby.h being missing. I can't quite get that complete absence replicated locally:

clang called with: -DENABLE_NLS -DHAVE_CONFIG_H -DHAVE_GCRYPT -DHAVE_GNUTLS -DHAVE_ICONV -DHAVE_ZLIB -DWEECHAT_LICENSE="GPL3" -DWEECHAT_VERSION="1.4" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_LARGE_FILES -Druby_EXPORTS -I/usr/local/include -I/tmp/weechat20160409-5702-zfw0tj/weechat-1.4/build -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0/universal-darwin15 -Wall -Wextra -Werror-implicit-function-declaration -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11 -fPIC -fPIC -fPIC -o CMakeFiles/ruby.dir/weechat-ruby.o -c /tmp/weechat20160409-5702-zfw0tj/weechat-1.4/src/plugins/ruby/weechat-ruby.c
superenv removed:  -I/usr/local/include -Wall -Wextra -Werror-implicit-function-declaration -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
superenv added:    -pipe -w -Os -march=native -isystem/usr/local/include -isystem/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/gettext/include -I/usr/local/opt/openssl/include -I/usr/local/opt/libressl/include -I/usr/local/opt/libxml2/include -I/usr/local/opt/curl/include
superenv executed: clang -pipe -w -Os -march=native -DENABLE_NLS -DHAVE_CONFIG_H -DHAVE_GCRYPT -DHAVE_GNUTLS -DHAVE_ICONV -DHAVE_ZLIB -DWEECHAT_LICENSE="GPL3" -DWEECHAT_VERSION="1.4" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_LARGE_FILES -Druby_EXPORTS -I/tmp/weechat20160409-5702-zfw0tj/weechat-1.4/build -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/include/ruby-2.0.0/universal-darwin15 -DNDEBUG -mmacosx-version-min=10.11 -fPIC -fPIC -fPIC -o CMakeFiles/ruby.dir/weechat-ruby.o -c /tmp/weechat20160409-5702-zfw0tj/weechat-1.4/src/plugins/ruby/weechat-ruby.c -isystem/usr/local/include -isystem/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/gettext/include -I/usr/local/opt/openssl/include -I/usr/local/opt/libressl/include -I/usr/local/opt/libxml2/include -I/usr/local/opt/curl/include

Interestingly I can get a failure (even if not this failure) if I punt Homebrew's Ruby to the front of the $PATH and then try to build here --with-ruby. That leads me this failure. I'm curious if these errors are somewhat similar to this Ruby issue from a while back.

@manavortex Do you have /sw in your $PATH?

@DomT4
Copy link
Member

DomT4 commented Apr 10, 2016

Doesn't seem to be OP's problem but I can't get weechat --with-ruby to build at all when Homebrew's Ruby is installed and linked. It looks like in that situation the build is trying to use the headers from the system Ruby and the library from Homebrew's Ruby.

@ilovezfs
Copy link
Contributor

@DomT4 I cannot reproduce what you're describing:
https://gist.github.com/ilovezfs/8eb441f8cd22dcbffbb8662a2513c12c

And

iMac-TMP:~ joe$ brew linkage weechat
System libraries:
  /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  /usr/lib/libSystem.B.dylib
  /usr/lib/libcurl.4.dylib
  /usr/lib/libiconv.2.dylib
  /usr/lib/libncurses.5.4.dylib
  /usr/lib/libz.1.dylib
Homebrew libraries:
  /usr/local/opt/gettext/lib/libintl.8.dylib (gettext)
  /usr/local/opt/gnutls/lib/libgnutls.30.dylib (gnutls)
  /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib (libgcrypt)
  /usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (libgpg-error)
  /usr/local/opt/ruby/lib/libruby.2.3.0.dylib (ruby)
Possible undeclared dependencies:
  libgpg-error, ruby
iMac-TMP:~ joe$

@ilovezfs
Copy link
Contributor

@manavortex Did you try with the empty brew installation?

@ilovezfs ilovezfs added the needs response Needs a response from the issue/PR author label Apr 10, 2016
@manavortex
Copy link
Author

Not yet - I’ll try tomorrow, okay? :)

On 10 Apr 2016, at 9:03, ilovezfs wrote:

@manavortex Did you try with the empty brew installation?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#117 (comment)

@ghost ghost removed the needs response Needs a response from the issue/PR author label Apr 10, 2016
@ilovezfs
Copy link
Contributor

@manavortex Sounds good.

@tdsmith tdsmith added the needs response Needs a response from the issue/PR author label Apr 10, 2016
@apjanke apjanke changed the title weechat 1.4 did not build weechat 1.4 --with-ruby did not build Apr 11, 2016
@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

What's in your /sw, manavortex? Is that a Fink installation?

@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

export PATH="/Users/manavortex/.rbenv/versions/2.2.3/include/ruby-2.2.0/ruby:$PATH"

This is a misunderstanding of the PATH environment variable, which is the set of paths to programs you can run in the terminal with using an absolute path. It doesn't have anything to do with header files.

In this case I think it may be relevant. $PATH is being used to locate the ruby command to determine which Ruby installation to build against. And that installation location determines the paths to the header files which are passed to the compiler. It looks like because the ruby it finds is a Fink installed one in /sw, then superenv is stripping the paths to its includes, because we don't support building against Fink or MacPorts packages.

superenv isn't adding any Ruby paths back in because there's no Ruby dependency in the formula.

I can reproduce on my machine by:

  • install Fink
  • fink install ruby20 ruby20-dev ruby20-shlibs
  • brew install weechat --with-ruby
[ 67%] Built target script
/Applications/Xcode-7.3.app/Contents/Developer/usr/bin/make -f src/plugins/ruby/CMakeFiles/ruby.dir/build.make src/plugins/ruby/CMakeFiles/ruby.dir/depend
cd /tmp/weechat20160411-31202-1834rdo/weechat-1.4/build && /usr/local/Cellar/cmake/3.5.1/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/weechat20160411-31202-1834rdo/weechat-1.4 /tmp/weechat20160411-31202-1834rdo/weechat-1.4/src/plugins/ruby /tmp/weechat20160411-31202-1834rdo/weechat-1.4/build /tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby /tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby/CMakeFiles/ruby.dir/DependInfo.cmake --color=
Dependee "/tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby/CMakeFiles/ruby.dir/DependInfo.cmake" is newer than depender "/tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby/CMakeFiles/ruby.dir/depend.internal".
Dependee "/tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby/CMakeFiles/ruby.dir/depend.internal".
Scanning dependencies of target ruby
/Applications/Xcode-7.3.app/Contents/Developer/usr/bin/make -f src/plugins/ruby/CMakeFiles/ruby.dir/build.make src/plugins/ruby/CMakeFiles/ruby.dir/build
[ 68%] Building C object src/plugins/ruby/CMakeFiles/ruby.dir/weechat-ruby.o
cd /tmp/weechat20160411-31202-1834rdo/weechat-1.4/build/src/plugins/ruby && /usr/local/Library/ENV/4.3/clang  -DENABLE_NLS -DHAVE_CONFIG_H -DHAVE_GCRYPT -DHAVE_GNUTLS -DHAVE_ICONV -DHAVE_ZLIB -DWEECHAT_LICENSE=\"GPL3\" -DWEECHAT_VERSION=\"1.4\" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D_LARGE_FILES -Druby_EXPORTS -I/usr/local/include -I/tmp/weechat20160411-31202-1834rdo/weechat-1.4/build -I/sw/include/ruby-2.0 -I/sw/include/ruby-2.0/x86_64-darwin  -Wall -Wextra -Werror-implicit-function-declaration -DNDEBUG -isysroot /Applications/Xcode-7.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11 -fPIC   -fPIC -fPIC -o CMakeFiles/ruby.dir/weechat-ruby.o   -c /tmp/weechat20160411-31202-1834rdo/weechat-1.4/src/plugins/ruby/weechat-ruby.c
/tmp/weechat20160411-31202-1834rdo/weechat-1.4/src/plugins/ruby/weechat-ruby.c:25:10: fatal error: 'ruby.h' file not found
#include <ruby.h>
         ^
1 error generated.
make[2]: *** [src/plugins/ruby/CMakeFiles/ruby.dir/weechat-ruby.o] Error 1
make[1]: *** [src/plugins/ruby/CMakeFiles/ruby.dir/all] Error 2
make: *** [all] Error 2

Seems like the thing to do is to have superenv remove Fink and MacPorts paths from $PATH when doing a build or test, to avoid detecting Ruby or other packages it's not compatible with.

Might need to add a Ruby dependency to this formula, too, to get it to build against a brewed Ruby under superenv.

@apjanke apjanke removed the needs response Needs a response from the issue/PR author label Apr 11, 2016
@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

Well, superenv is already sanitizing the $PATH. I don't know why it's picking the Fink Ruby and coming up with -I/sw paths. It's using CMake to detect the Ruby installation. And it looks like it's finding it through the pkg-config detection mechanism. But I don't see why it's finding the /sw one.

@manavortex
Copy link
Author

@ilovezfs: It did not build. :D

https://gist.github.com/baa2236e53631d612db942a4ee8b2b82

@apjanke:
I have fink in my /sw, yes.
bin/ etc/ fink/ include/ lib/ sbin/ share/ src/ var/

Did you check out my "fix" in the OP? I suppose that might give someone who really knows what they are doing instead of just blindly poking around in sources some additional insight into the problem.

@ilovezfs
Copy link
Contributor

@manavortex Do you intentionally still have that fink installation?

mkdir ~/Documents/fink-2016-04-11
sudo mv /sw  ~/Documents/fink-2016-04-11
brew reinstall --with-ruby weechat

@manavortex
Copy link
Author

@ilovezfs - that did it! 👍

@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

Here is a fix to the formula to prevent it from picking up the Fink-installed Ruby.

This gets it to build okay against the system ruby when no brewed ruby is installed. When a brewed ruby is installed, it gets the same undefined _rb_funcall2 link error that Dom observed.

[ 69%] Linking C shared module ruby.so
cd /tmp/weechat20160411-68061-18wusr/weechat-1.4/build/src/plugins/ruby && /usr/local/Cellar/cmake/3.5.1/bin/cmake -E cmake_link_script CMakeFiles/ruby.dir/link.txt --verbose=1
/usr/local/Library/ENV/4.3/clang    -Wall -Wextra -Werror-implicit-function-declaration -DNDEBUG -isysroot /Applications/Xcode-7.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11 -bundle -Wl,-headerpad_max_install_names  -o ruby.so CMakeFiles/ruby.dir/weechat-ruby.o CMakeFiles/ruby.dir/weechat-ruby-api.o /usr/local/lib/libruby.dylib ../libweechat_plugins_scripts.a 
Undefined symbols for architecture x86_64:
  "_rb_funcall2", referenced from:
      _protect_funcall0 in weechat-ruby.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I think it's probably a related issue: the CMake code it uses to detect Ruby does not actually find the brewed ruby, so it detects the system ruby and uses those headers, but superenv ends up pointing at the brewed ruby libs inside the compiler invocations.

Fiddling a bit more with CMAKE env variables that find_program uses seems like it ought to do it.

@ilovezfs
Copy link
Contributor

@apjanke Hmm ... isn't this something we should actually address in superenv instead?

@manavortex
Copy link
Author

I'm not scared when it comes to digging into source code head first, but I think this might make some of the more reluctant users quite scared. A fix would be appreciated. :)

@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

@apjanke Hmm ... isn't this something we should actually address in superenv instead?

Probably, but I don't know if we can fully. I can't tell where it's getting the /sw paths from in the first place, since superenv is already removing /sw from $PATH. And there are some issues with the weechat CMake files, so I think some changes will need to be done there regardless.

Anybody know CMake well enough to know how it's choosing to look in /sw for this Ruby stuff, even though /sw has been removed from the path? It locates it even if I haven't set up Fink paths in my current shell in the first place.

At any rate, the FindRuby.cmake file in WeeChat looks like one they adapted from an earlier version of CMake, before Kitware/CMake@cde1005. It searches separately for the ruby command and the Ruby library, using a different list of possible versions for the two things, and specifying PATHS instead of HINTS, which I think will search the default paths first. That explains why it could find headers from one Ruby and libs from another.

I'll hack on this some more tomorrow. But I think there's an upstream bug report in here even if we can get it tamped down using superenv.

@manavortex
Copy link
Author

Anybody know CMake well enough to know how it's choosing to look in
/sw for this Ruby stuff, even though /sw has been removed from the
path? It locates it even if I haven't set up Fink paths in my current
shell in the first place.

I have no idea concerning CMake, but my dirty fix included editing a
Makefile with the paths of the missing file. Wouldn’t it work to say
:require “ruby”, then get the ruby path via brew, and throw that
into the makefile?

@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

Oh, here we go, I think. superenv is setting $CMAKE_PREFIX_PATH. But there's also a CMAKE_SYSTEM_PREFIX_PATH. I dumped it out during the build, and there's /sw.

CMAKE_SYSTEM_PREFIX_PATH: /usr/local;/usr;/;/usr/local/Cellar/cmake/3.5.1;/usr/local/Cellar/weechat/1.4_2;/Applications/Xcode-7.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr;/sw;/opt/local

And here are the hardcoded Fink and MacPorts paths in Modules/Platform/Darwin.cmake in the CMake source tree.

list(APPEND CMAKE_SYSTEM_PREFIX_PATH
  /sw        # Fink
  /opt/local # MacPorts
  )

I bet that's where /sw is coming from.

/usr/local is still supposed to be ahead of it on that search path, so I don't know why it's getting ruby from /sw instead of the brewed one. But this at least is an explanation for how it's findable at all.

Here's a problem with setting CMAKE_PREFIX_PATH: the search order for find_library and find_program is this:

  1. Paths from cmake cache variables (CMAKE_PREFIX_PATH etc)
  2. Paths from cmake-specific env variables ($CMAKE_PREFIX_PATH etc)
  3. HINTS option to find_xxx()
  4. Standard system env vars ($LIB, $PATH)
  5. Platform cmake variables: CMAKE_SYSTEM_PREFIX_PATH etc
  6. PATHS option to find_xxx()

The HINTS option is how the library paths associated with the located ruby program are propagated to find_library. But that's step 3, and we're setting $CMAKE_PREFIX_PATH in superenv, that generic search path takes precedence. In this case, the /usr/local in $CMAKE_PREFI_PATH is masking the /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib identified from the system ruby.

Maybe we should be setting CMAKE_SYSTEM_*_PATH instead of CMAKE_*_PATH in superenv, to allow path resolution like this inside the build scripts to work. (And to let us remove /sw and /opt/local from the search sequence entirely.)

This is also complicated by the fact that their cmake files prefer ruby programs with version suffixes over a plain ruby. And Fink installs a ruby2.0, so it will take precedence over the system and brewed rubys if /sw is on the search path, even if it's after /usr/bin and /usr/local/bin.

I've hacked the weechat formula enough that it will now build against either the system or brewed rubyhttps://github.com/apjanke/homebrew-core/commit/2bdd5a21de4aafe992ef902236353e36604663e4 – but it only works if you change those CMAKE_*_PATH variables to CMAKE_SYSTEM_*_PATH. (I'm not sure they even do anything at that point; they may need to be specified as cmake variables instead of env variables.)

I'm pretty sure the Ruby detection logic in weechat ought to be changed to avoid problems on systems with multiple ruby installations. (This isn't just Homebrew-specific: it looks like there are other cases where it'll pick headers from one ruby and libs from another. Though setting CMAKE_PREFIX_PATH makes it very likely to happen.) Not sure if we should switch to CMAKE_SYSTEM_* variables for the general case.

@apjanke apjanke added the upstream issue An upstream issue report is needed label Apr 11, 2016
@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

I have no idea concerning CMake, but my dirty fix included editing a Makefile with the paths of the missing file. Wouldn’t it work to say :require “ruby”, then get the ruby path via brew, and throw that into the makefile?

Let's try to get it working with the CMake build system first. Hacking the generated Makefile is going to be brittler.

@ilovezfs
Copy link
Contributor

@apjanke I think we should probably make this test more sensitive: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac.rb#L204-L235

Or at least add a more sensitive version of it to doctor or both.

@ilovezfs
Copy link
Contributor

@manavortex It seems that the reason you didn't get a warning at the very beginning from both brew install and brew doctor is that /sw/bin/fink didn't exist on your system. Were the files in /sw a fink installation that you thought you'd uninstalled at some point, a current fink installation, or something else? I'm confused how it could be that fink ruby would be in /sw but /sw/bin/fink not be present.

@manavortex
Copy link
Author

Actually, I have no idea - I’ve not installed fink since I’m running
El Capitan, but before..? I have no idea.

Were the files in /sw a fink installation that you thought you'd
uninstalled at some point, a current fink installation, or something
else? I'm confused how it could be that fink ruby would be in /sw
but /sw/bin/fink not be present.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#117 (comment)

@ilovezfs
Copy link
Contributor

@manavortex Do you mind posting the output of find ~/Documents/fink-2016-04-11 in a gist?

@manavortex
Copy link
Author

@ilovezfs Not at all, here you go:
https://gist.github.com/manavortex/559ec80a99eadb11a6b5536204508d92

@manavortex Do you mind posting the output of find ~/Documents/fink-2016-04-11 in a gist?

@ilovezfs
Copy link
Contributor

@manavortex Well the mystery is why /sw/bin/fink isn't in that list. If it had been, the problem would have been flagged by brew from the very beginning, but I think we can close this because that should be a highly unusual situation. If you can recall what could have happened to /sw/bin/fink, that would be good to know.

@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

@DomT4: I can't reproduce the --with-ruby build failure without Fink installed either. Could be another interaction. Would you mind adding the output of brew ls to the gist from your build failure?

@apjanke
Copy link
Contributor

apjanke commented Apr 11, 2016

I posted an upstream issue report: weechat/weechat#714

@apjanke
Copy link
Contributor

apjanke commented Apr 12, 2016

Yeah, I think we can close this too: it's an unusual situation, and OP's problem has been worked around. Sound good, @manavortex?

I've posted the general form of the CMake/Fink interaction issue at Homebrew/brew#72 so we can track and eventually fix it, But it's a separate issue so it focuses on the structural problem, and won't spam manavortex with updates about the core code that aren't relevant to this particular installation problem.

@pkgw pkgw mentioned this issue Jul 8, 2017
6 tasks
@Homebrew Homebrew locked and limited conversation to collaborators May 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
upstream issue An upstream issue report is needed user configuration User configuration rather than a Homebrew issue
Projects
None yet
Development

No branches or pull requests

5 participants