Install fails on RHEL6, v1.2.7

[ryanschwartz]

Version 1.2.7 fails to install on RHEL6.1. Version 1.2.6 installs fine. Output of build failure and gem_make.out at https://gist.github.com/868793135b0d8db77c70

Libraries and devel headers are installed for sasl, libmemcache, and memcache:

[vstsbx01:~] root# rpm -qa|egrep 'sasl|memcac'|sort cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-devel-2.1.23-8.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 libmemcached-0.31-1.1.el6.x86_64 libmemcached-devel-0.31-1.1.el6.x86_64 memcached-1.4.4-3.el6.x86_64 memcached-devel-1.4.4-3.el6.x86_64

[jacksmith117]

Same issue with 1.2.7+ on Ubuntu 11.04, 1.2.6 installs without any problems too.

[evan]

Brandon, can you take this one?

[avsej]

Hi guys and @rhettc. could you post here output of ls -l /bin/sh I guess you have /bin/dash there. Try to re-link it to /bin/bash. I had similar issues on debian when maintainers were amending that link.

[rhettc]

Heylo, @avsej here is the output of the command. Looks like bash lrwxrwxrwx 1 root root 4 Sep 22 01:29 /bin/sh -> bash

If that's not what you were look for, lmk

[evan]

See if current master works for you.

[rhettc]

Same symptoms. This was what I did after I cloned the repository

rvmsudo rake manifest
rvmsudo rake install
rake build_gemspec
gem build memcached.gemspec
rvmsudo gem install memcached --version '1.3.4'

[evan]

What about just running "rake clean && rake compile"?

[rhettc]

Same results with rake clean && rake compile.

I'll just use that for future tests. The other steps were just what I came up with from various sources. I am not a Ruby veteran, so I'm sure I'm not going to come up with the most efficient means... :)

Let me know if you'd like me to put the output into pastebin or whatever.

[evan]

Do you have gettext installed?

[rhettc]

I don't but, I have v .17 in the yum repository, that I can install quickly.

[evan]

See if that helps...Google suggests it's related to AC_LIB_HAVE_LINKFLAGS.

[rhettc]

I installed gettext and then performed another

rake clean && rake compile

Still have the same symptoms. I appreciate your ongoing assistance!

[evan]

Can you unpack 1.2.6 and maybe compare the configure phases to see what changed?

[rhettc]

The first thing I notice is when setting CFLAGS on 1.3.4 there is this extra definition

CC="gcc"

that appears before

2>&1 

I have both versions on pastebin

1.2.6 http://pastebin.com/x46w2tTR 1.3.4 http://pastebin.com/3HVAjiyL

is this what you were looking for?

[evan]

This is interesting to me:

* 31 ** ! checking for ANSI C header files... yes --- 43 ---- ! checking for ANSI C header files... no

---

[rhettc]

Agreed. I'm looking into that on this end. If there is anything in particular I should focus on let me know. I'm going to look at the differences in the configure scripts b/w the versions.

[evan]

That sounds good. Focus on the 1.2.6 to 1.2.7 switch; no need for later changes.

[rhettc]

Ah right, well before I saw this I was in the midst of my comparison b/w 1.3 and 1.2.6. I think the findings are still relevant, though.

File: Configure was added and updated with the commits below.
SHA: 7648971e9ac9f2453738958576d7ed170b0a8fbc SHA: 09fef94f7a867847ee935b3aa955e9b9078d788d

During 1.2.6 config was scripted to use a much more simple looking test for the ANSI C headers. In later versions the test is more complex (perhaps because the testing macro is inlined/expanded, i guess) and broken.

_Before/Simple_ 1.2.6

if ac_fn_c_try_compile "$LINENO"; then :
  ac_cv_header_stdc=yes
else
  ac_cv_header_stdc=no
fi

_After/Complex_ 1.3

eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
$as_echo "$ac_try_echo") >&5
  (eval "$ac_compile") 2>conftest.er1
  ac_status=$?
  grep -v '^ *+' conftest.er1 >conftest.err
  rm -f conftest.er1
  cat conftest.err >&5
  $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
  (exit $ac_status); } && {
         test -z "$ac_c_werror_flag" ||
         test ! -s conftest.err
       } && test -s conftest.$ac_objext; then
  ac_cv_header_stdc=yes
else
  $as_echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5

        ac_cv_header_stdc=no
fi

For the 1.3 version, I was able to analyze the configure scripts and logs to recreate the first C program it makes to test the headers. I can compile and run the program, and it seemed like configure could too, but then failed the subsequent tests it performed, beforing setting ac_cv_header_stdc.

I think it was this patch file that properly altered the configure script used in version 1.2.6 so that it used a more robust macro (i guess) when checking for the headers.

[evan]

Oh, that's strange. So there was a ./configure patch that had crept into the build? That explains why re-running autoconf doesn't work.

If you can restore the original patched ./configure script, or re-apply the patch to the current ./configure, that should work for now. It is odd that upgrading autoconf breaks things though.

[rhettc]

Hmm, the sasl.patch touches a lot more files than just the configure script. I tried to apply the patch to the current ./configure script, but a dry run did not look promising since several hunks in the patch couldn't be resolved.

I have yet to try to move the patched ./config script in 1.2.6 to the 1.3 build, but it's on my list.

At the moment I'm installing GNU SASL. Maybe that will work better than the Cryus SASL packages I've been working with.

I'm definitely over my head here, but I'll see what I can do :)

[avsej]

@rhettc could you post your make output here?

[evan]

Cyrus SASL is correct. The code portions of the patch are already applied, AFAIK.

[rhettc]

@evan Cyrus is ok, understood. When i copied the patched 1.2.6 ./configure script to my 1.3.3 folder the configure phase worked, but then running "rake clean && rake compile" failed when making libmemcached. There were complaints about undefined references to some sasl functions. I haven't combed through the Google results fully, but there are some references to this on the bug tracking site for libmemcached that mentioned changing the order of linking. I'm not sure how relevant that is, just wanted to mention. Here's the paste from that failed 1.3.3 build with the 1.2.6 config copied over

[rhettc]

@avsej to clarify, I'm more than happy to post the output, which scenario (esp version) did you want to see?

[rhettc]

@evan oh also, regarding the sasl.patch file. It updates files, besides configure, that are related to configure/make process.
Here's a list of all the files not ending in .h or .c in the sasl patch

_diff -rcN a/libmemcached-0.32/aclocal.m4 b/libmemcached-0.32/aclocal.m4_ diff -rcN a/libmemcached-0.32/clients/Makefile.am b/libmemcached-0.32/clients/Makefile.am diff -rcN a/libmemcached-0.32/clients/Makefile.in b/libmemcached-0.32/clients/Makefile.in diff -rcN a/libmemcached-0.32/config.h.in b/libmemcached-0.32/config.h.in diff -rcN a/libmemcached-0.32/configure b/libmemcached-0.32/configure diff -rcN a/libmemcached-0.32/docs/Makefile.am b/libmemcached-0.32/docs/Makefile.am diff -rcN a/libmemcached-0.32/docs/Makefile.in b/libmemcached-0.32/docs/Makefile.in diff -rcN a/libmemcached-0.32/docs/memcached_sasl.pod b/libmemcached-0.32/docs/memcached_sasl.pod diff -rcN a/libmemcached-0.32/libmemcached/Makefile.am b/libmemcached-0.32/libmemcached/Makefile.am diff -rcN a/libmemcached-0.32/libmemcached/Makefile.in b/libmemcached-0.32/libmemcached/Makefile.in diff -rcN a/libmemcached-0.32/libmemcached/memcached_configure.h.in b/libmemcached-0.32/libmemcached/memcached_configure.h.in diff -rcN a/libmemcached-0.32/libmemcachedutil/Makefile.in b/libmemcached-0.32/libmemcachedutil/Makefile.in _diff -rcN a/libmemcached-0.32/m4/pandora_have_sasl.m4 b/libmemcached-0.32/m4/pandora_have_sasl.m4_ diff -rcN a/libmemcached-0.32/Makefile.in b/libmemcached-0.32/Makefile.in diff -rcN a/libmemcached-0.32/support/Makefile.in b/libmemcached-0.32/support/Makefile.in diff -rcN a/libmemcached-0.32/tests/Makefile.in b/libmemcached-0.32/tests/Makefile.in diff -rcN a/libmemcached-0.32/tests/output.cmp b/libmemcached-0.32/tests/output.cmp

[evan]

Try current master; I restored all the old build scripts.

[rhettc]

The symptoms look the same both when: 1) after a fresh clone rake clean && rake compile. This is the failure during the config phase with the complaints about AC_LIB_HAVELINKFLAGS. However, I do think I saw that the ANSI C headers were recognized, I will double check on that. 2) after failing in the scenario above, copy the config script from 1.2.6. Now we can get past the config phase but have problems when making as described in my previous comment referring to the undefined sasl calls.

[evan]

Ok, if that's the case then the issue is most likely with ext/extconf.rb and friends, not the configure itself. Want to investigate what changed there?

[rhettc]

Sure thing. Can you clarify "friends" do you mean the other ruby scripts in that directory? This issue is my first time dealing with gem installation at this level of detail. :)

[evan]

Yeah, extconf-make.rb is the other one.

[rhettc]

ok. I'll be looking into that.

I need to follow up on the earlier results. Since my last comment I had reinstalled cyrus-sasl and then rake compile and I got through the first configure of libmemcached but after the rake process moved to the "making libmemcached" phase there was another configure of libmemcached this time the configure fails. Note also that the configure properly detects ANSI C headers on the first pass, but the second configure phase it does not. That second configure fails with the AC_LIB_HAVE_LINKFLAGS errors that we've seen.

Why does it do a second configure for libmemcached, I wonder? It won't do that if the 1.2.6 config file is used instead.

[evan]

I don't know why it happens twice.

[avsej]

Just pushed fix in pull request #68

[rhettc]

Same symptoms with your fork. ingenthr asked that I post this issue to couchbase.org/isues. You can refer to that issue here

[avsej]

I consider when you say symptoms you are meaning libmemcached compilation fails. Your previous log show the same issue I have on my fresh RHEL6 box and the latter patch fixes it. @evan, could you, please review changes? But your new log show that some macro cannot be found in your autotools installation. I think this is another issue and it could be caused by 3f2dc77a after autoreconf. I need to check on amazon linux (which is modified RedHat).

[avsej]

BTW I've just confirmed that my patch is working on amzn-ami-2011.09.1.i386-ebs (ami-7f418316)

Description:	Amazon Linux AMI i386 EBS
Status:	available
Platform:	Amazon Linux
Image size:	8 GB
Visibility:	Public
Owner:	amazon (137112412989)

Could you post output of sudo yum list installed? Here is mine https://gist.github.com/1271057

[avsej]

@rhettc I guess you doesn't have gcc-c++ installed :)

[rhettc]

I forked your gist with my list. It looks like these are the items that I don't have, but you do.

cronie.i686 cronie-anacron.i686 crontabs.noarch mgetty.i686 ruby-devel.i686 sendmail.i686

Oh and regarding your question/comment, above: Yes I meant that the libmemcached compilation fails.

[rhettc]

I have this package gcc-c++.i686

Why do you ask? And do you think my earlier comment may be relevant https://github.com/fauna/memcached/issues/52#issuecomment-2304077

Thanks

[rhettc]

Ok so it seems like the issue is related to rvm or ruby 1.9.2

Was able to use install the gem on a fresh AWS instance that used the 1.8.7 ruby without rvm.

Refer to this gist for the steps https://gist.github.com/1271242/51db269cdd2cd75913384671dd12661a27d827f0

Using this commit SHA: 754ae8598c20dab8762d8c89265605d8769113ee that is pending this pull request

[avsej]

I'm checking 1.9.2 on my instance now

[avsej]

Verified on the same amazon instance for ruby 1.9.2 under rvm. It's OK. rvm info

[evan]

Should I do a release?

[avsej]

I think we can close the issue unless @rhettc can reproduce it on his clean instance or provide some additional input.

[rhettc]

I continued to work on the clean instance by installing rvm and ruby 1.9.2. rvm was set to use 1.9.2 and then I went back to the memcached gem's folder and was able to rake compile the memcached gem.

This gist has the steps taken at the terminal.

Verified.

Please note, this is a bit different from original setup, mainly: 1) originally I installed RVM before any attempts to install the memcached gem 2) originally I installed RVM in multi-user mode which leads subsequent commands to be issued using rvmsudo. For example: "rvmsudo rvm rake compile" vs. "rake compile"

[evan]

Ok, it sounds like rvmsudo is damaging your link environment somehow. I am going to release this build and close for now. Thanks both of you for all your help.

[rhettc]

I concur. Even if this build release doesn't fix all permutations of the issue it should clear up several of them. And for those that it doesn't handle, they are not any better or worse off than before.

Thanks to you both for taking care of this, and for your patience It was valuable learning experience, I'm glad to have participated.

I'm going to keep my old broken EC2 instance around for a bit, so I'm available for further testing if the need arises.