weechat build fails with ruby 1.9.3p194 from rvm

[kevwil]

Doctor and build output: https://gist.github.com/2769679

If I add "--disable-ruby" to the configure args, it will install correctly.

Ruby seems to run just fine.

[adamv]

I don't see the build output on that link.

[kevwil]

Hmmm, Gist is refusing to save that content. I tried five times but it thinks the content is empty. Must be a parser error.

Here's the output file from my Dropbox: http://dl.dropbox.com/u/44171220/brew_install_weechat.txt

[2bits]

If you click on Create Public Gist and it comes back with a blank looking page that looks like this gist, then your gist was created ok, but you have to use the View Raw hyperlink. I'm not sure why this happens.

Please brew install -vd weechat again and when it fails to compile, gist the config.log it leaves behind in the top level of the build tree. I'm sorry about the hassles you get with this. I worked a long time to change weechat over from using CMake to use configure to get around the problems building the ruby bindings, and it worked for rbenv. Because I don't use rbenv or rvm, I didn't have a way to test it correctly. Even if I installed rvm, I wouldn't know how to use it. So I failed, which is a drag.

That being said, can you be sure it's not the Mono framework? Could you temporarily move it out of /Library and try it again like this

sudo mv /Library/Frameworks/Mono.framework ~/mono
brew install -vd weechat
sudo mv ~/mono /Library/Frameworks/Mono.framework

[2bits]

Please also gist your brew --config. Thanks.

[kevwil]

I submitted a bug report to weechat. https://savannah.nongnu.org/bugs/?36526

[kevwil]

Output of brew --config and output of brew install -vd weechat both before and after moving Mono out of the way: https://gist.github.com/2770395

[2bits]

Thanks for the info. It's showing

RUBY='/Users/sensei/.rvm/rubies/ruby-1.9.3-p194/bin/ruby'
RUBY_CFLAGS='-I/Users/sensei/.rvm/rubies/ruby-1.9.3-p194/include/ruby-1.9.1/ -I/Users/sensei/.rvm/rubies/ruby-1.9.3-p194/include/ruby-1.9.1/x86_64-darwin11.3.0 -DRUBY_VERSION=191'
RUBY_LFLAGS='-lruby.1.9.1'

I'm not sure why it's doing that. I'll wait to see what they say in your bug report. In the meantime, can you tell me what you get for

find /Users/sensei -name libruby\*

[kevwil]

I get:

/Users/sensei/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.1.9.1-static.a /Users/sensei/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.1.9.1.dylib /Users/sensei/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.1.9.dylib /Users/sensei/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.dylib /Users/sensei/.rvm/src/ruby-1.9.3-p194/libruby.1.9.1-static.a /Users/sensei/.rvm/src/ruby-1.9.3-p194/libruby.1.9.1.dylib /Users/sensei/.rvm/src/ruby-1.9.3-p194/libruby.1.9.dylib /Users/sensei/.rvm/src/ruby-1.9.3-p194/libruby.dylib

[2bits]

Ok that's good news. It has the name of the library correct, but it just needs the path /Users/sensei/.rvm/rubies/ruby-1.9.3-p194/lib added to the search paths where it looks for libs (normally just /usr/lib:/usr/local/lib). I should be able to do something about that depending on what the weechat devs decide to do.

[kevwil]

FYI I'm going to experiment with rbenv and see if it handles this better, but I may not get around to that for a few days.

[adamv]

Sounds like an upstream RVM issue, or possibly a weechat config issue; not a Homebrew issue per se.

[kevwil]

perhaps the homebrew formula should have a --disable-ruby arg that passes down to the ./configure script so that weechat/ruby problems can be side-stepped?

[adamv]

It should probably have an --enable-ruby call to opt in, for all langs.

[2bits]

@adamv I'll make the bindings opt in rather than the default. @kevwil I wouldn't switch to rbenv just yet, because we'd like you to be able to test any fixes weechat makes and our adjustments to the formula too. While rvm seemed elegant when I read about it, rbenv was the exact opposite. Plus they were no help when I asked them if cmake was finding their Ruby environment correctly. It can't be that hard to look at a variable and say it's correct or not, but that was too much to ask.

[kevwil]

@2bits it seems the upstream bug handler wants homebrew to use cmake instead of configure. We're waiting on them, they're waiting on us, round and round we go.

[2bits]

Frack. I switched the formula from cmake to configure a month ago because cmake couldn't build the ruby bindings against rbenv. With configure it can't build the ruby bindings against rvm. When I asked the rbenv developers for help, they ignored me. I can't win, and I don't know what to do.

[kevwil]

I relayed this to the upstream bug report. https://savannah.nongnu.org/bugs/?36526

Perhaps for now we need to just disable ruby support? Does the new weechat 0.3.8 behave any differently?

[2bits]

Well the ruby bindings work when built against the system ruby using cmake or configure. So to leave those bindings as options like they are now seems reasonable. I'm happy to go back to using CMake if that's the preferred build method, but it's asking a lot of the admins here to accept all this back and forth when the end result is the bindings still don't work for some people. Thanks for the info on the new version. We can upgrade to that and try it.

[2bits]

I see from the bug report that the devs say configure is deprecated and support is made primarily for weechat when built using cmake. Because the aspell pull request just landed, I will go ahead and modify weechat to build that plugin as an option and switch the whole thing back to a cmake build. The devs seem helpful and interested in getting this resolved. So it makes sense to do what we can on our end. Plus I'd rather have the ruby bindings working for rvm.