MacPorts OpenSSL breaks a new Ruby release

[joelmichael+macports@…]

I'm a Ruby on Rails developer and we tend to use bleeding edge versions of Ruby installed via RVM instead of the one provided by MacPorts.

There's a bug in the new release of Ruby 1.9.2-p180, and according to the guys over at the Ruby ticket manager, it's a problem with OpenSSL in MacPorts. I like MacPorts and would prefer not to switch to something else, so I figured I'd post this here and see if you guys are interested in investigating the issue.

One of the related tickets over at Ruby's Redmine: ​http://redmine.ruby-lang.org/issues/4370

Thanks.

[jmroot (Joshua Root)]

The linked ticket doesn't make it quite clear what is happening. Was this happening with ruby19 installed with MacPorts? Or was it a manual build that happened to pick up (some parts of?) MacPorts OpenSSL?

[joelmichael+macports@…]

It was a manual build of Ruby 1.9.2 p180 via RVM. I suspect it's possibly because the MacPorts OpenSSL rolled over to 1.0.0 and maybe had some API changes. Unfortunately, it's a required dependency for mysql.

Honestly, I've just switched to homebrew anyway, which is what most Ruby on Rails developers use now. It didn't install a new OpenSSL but just used the built-in one.

[danielluke (Daniel J. Luke)]

My initial impression from the other ticket was that the problem wasn't an openssl bug, but that the two programs were linking to different versions of openssl (system vs. macports one).

Building Ruby 1.9.2-p180 in macports (or against the macports-installed libs) would then solve the issue.

[mark_macports@…]

I tried building Rub 1.9.2-p136 against macports openssl

rvm install 1.9.2-p136 -C --enable-shared,\
  --with-openssl-dir=/opt/local/etc/openssl,\
  --build=x86_64-apple-darwin10[[BR]]

Still segfaulting for me. To repro, just did this from rails console:

imap = Net::IMAP.new('imap.gmail.com', 993, true)

[mark_macports@…]

Cc Me!

[mark_macports@…]

Replying to mark_macports@…:

Cc Me!

co-worker found tip in ​https://github.com/drewblas/aws-ses#readme to set this environment variable: RUBYOPT=-r openssl

tested and is working on OSx 10.6.6. I had been running into the segfault w/ imap over ssl.

And there was much rejoicing...

[kimuraw (kimura wataru)]

Hi Mark,

You mean that?

• run ruby with RUBYOPT=-ropenssl => OK
• run ruby without RUBYOPT=-ropenssl => NG

If YES, please show me the result of the following commands.

$ DYLD_PRINT_LIBRARIES=1 ruby1.9 -e 'require "openssl"' 2>&1 | grep -i ssl
$ DYLD_PRINT_LIBRARIES=1 ruby1.9 -ropenssl -e '' 2>&1 | grep -i ssl

This is the result on my Mac with port:ruby19.

$ DYLD_PRINT_LIBRARIES=1 ruby1.9 -e 'require "openssl"' 2>&1 | grep -i ssl
dyld: loaded: /opt/local/lib/ruby1.9/1.9.1/universal-darwin10/openssl.bundle
dyld: loaded: /opt/local/lib/libssl.1.0.0.dylib
$ DYLD_PRINT_LIBRARIES=1 ruby1.9 -ropenssl -e '' 2>&1 | grep -i ssl
dyld: loaded: /opt/local/lib/ruby1.9/1.9.1/universal-darwin10/openssl.bundle
dyld: loaded: /opt/local/lib/libssl.1.0.0.dylib

[mark_macports@…]

Hi.

You mean that?

• run ruby with RUBYOPT=-ropenssl => OK
• run ruby without RUBYOPT=-ropenssl => NG

Correct .

$ DYLD_PRINT_LIBRARIES=1 ruby1.9 -e 'require "openssl"' 2>&1 | grep -i ssl
$ DYLD_PRINT_LIBRARIES=1 ruby1.9 -ropenssl -e '' 2>&1 | grep -i ssl

Both return nothing on my Mac.

This is the result on my Mac with port:ruby19.

Did you install Ruby w/ port? I did not. I did use port to install mysql5, mysql5-server, libxml2 libxslt I am running RVM 1.2.7.

HTH, Mark

[jmroot (Joshua Root)]

There isn't any real evidence here that macports is doing anything wrong, as opposed to the non-macports ruby being built wrong. In fact the ruby19 port working fine suggests the opposite.

Either way, there isn't really much that can be done without further info regarding what exactly is (allegedly) wrong with openssl. If I was the maintainer, I would have closed this months ago TBH.

[kimuraw (kimura wataru)]

I close this ticket. The ruby's redmine ticket says this problem was solved with other reasons.

​https://redmine.ruby-lang.org/issues/4370#note-4