Can't build on 32-bit Fedora 8

[wincent]

libmemcached won't build on 32-bit Fedora 8 unless --disable-64bit CFLAGS="-march i686" is passed to ./configure.

Due to this I've found that I can't build the gem using gem install memcache, nor any incantation of gem install memcache -- --extra-flags-here. There is an $EXTRA_CONF global variable that is referenced in the ext/extconf.rb, but I am ignorant of how to get custom build settings into that global:

Unfortunately, this doesn't work:

gem install memcache -- --disable-64bit CFLAGS+=' -march=i686'

The first few lines of the failed gem_make.out read as follows, so I see the switches getting passed to extconf.rb, but they evidently don't make it to the configure line:

/usr/bin/ruby extconf.rb --disable-64bit CFLAGS+= -march=i686
Building libmemcached.
tar xzf libmemcached-0.38.tar.gz 2>&1
env CFLAGS='-fPIC' ./configure --prefix=/data/rails/deploy/shared/bundle/ruby/1.8/gems/memcache-1.2.12/ext --without-memcached --disable-shared --disable-utils --disable-dependency-tracking  2>&1

The only way I've been able to get it to build is by hand-editing the ext/extconf.rb file to include those flags.

I see that the memcached project does have some platform-specific stuff in its extconf.rb (see the Solaris-specific stuff):

http://github.com/fauna/memcached/blob/master/ext/extconf.rb

I wonder if something similar could be done here?

Output of ruby -r rbconfig -r pp -e 'pp RbConfig::CONFIG.sort' on 32-bit Fedora 8 appears here:

http://gist.github.com/558863

Perhaps if target_cpu is i686 as it is here, -march=i686 could be added to the CFLAGS. I am not sure what test would need to be applied to check for 32-bit vs 64-bit systems (for the --disable-64bit flag).

As an aside, I did look at using an "external" libmemcached on the machine so that the memcache gem could just pick that up. This requires the EXTERNAL_LIB variable to be set in the environment.

Seems like it could work with env EXTERNAL_LIB=1 gem install memcache, but that won't help with Bundler-based deployment because Bundler only allows you to set up build options that appear after the gem install (ie. gem install memcache -- EXTERNAL_LIB=1, which doesn't get picked up inside the extconf.rb as far as I can tell).

I guess the extconf.rb could be customized to look at ARGV for patterns of the form x=y and possibly act on them. No idea if there are precedents for this though.

For reference, upstream bug in libmemcached tracker:

https://bugs.launchpad.net/libmemcached/+bug/516774

Anyway, sorry about the monster ticket. Interested to hear your input on any of these points. My workaround in the meantime is to patch and build by hand, and set Bundler to use a shared BUNDLE_PATH; that way it doesn't try to rebuild the gem on each deployment (which would fail).

Cheers,
Wincent

[ninjudd]

I just checked in a fix to pass the opts after -- through to configure.

So, you should now be able to install with:
gem install memcache -- --disable-64bit CFLAGS=-march=i686

Let me know if it works for you.

Thanks,
Justin

[ninjudd]

Actually, it looks ruby escapes the args strangely, so you may need to do:
gem install memcache -- --disable-64bit "CFLAGS='-march=i686'"

[wincent]

Yes, I noticed the weird escaping in my own testing.

Thanks for this. I just tested it and can confirm that the args do get passed through to configure and the gem install succeeds.

The other workaround that I had, which also works, is to build libmemcached first separately, and then install using:

env EXTERNAL_LIB=1 gem install memcache

For this to actually work in a Bundler context, I had to do it setting GEM_HOME to match my eventual shared BUNDLE_PATH:

env GEM_HOME=/path/to/shared/bundle/ruby/1.8 EXTERNAL_LIB=1 gem install memcache

And then when running bundle install, pass it --path /path/to/shared/bundle. And voila, it works also.

So it's nice to have both options as workarounds for now, although to be honest, I like the one you've implemented in your patch the best.

Cheers,
Wincent