Source build w/memcached and/or fastcgi support fails

Description

I'm building Shibboleth SP from source on RHEL 5.9 with support for the memcached storage provider, which is installed in a custom directory. I.e., I'm invoking configure like this:

When adding the --with-memcached line the builds fails; otherwise it's fine.
I found two problems:

  1. The memcached header presence check ran by ./configure fails because the necessary -I flag is not on the command line. I've verified this in config.log:

  2. The build inside memcache-store fails for the same reason: missing -I flag:

I'm relatively new to autotools, but it seems to me like this is due to two separate issues with configure.ac and memcache-store/Makefile.am:

configure.ac

For the first issue, notice that in configure.ac MEMCACHED_INCLUDE is not added to any variable contributing to the final g++ flags, thus leading to the necessary -I flag not being there at the time AC_CHECK_HEADER does its thing. Google tells me that common practice seems to be to temporarily add it to the CPPFLAGS; something like this:

configure.ac'

This solved the missing header check for me, but I will leave its correctness up to your judgement.

For the second issue, the problem seems to be with memcache-store/Makefile.am:

memcache-store/Makefile.am

MEMCACHED_CFLAGS appears nowhere else in the distribution tree, so it seems like that should've been MEMCACHED_INCLUDE. Also, MEMCACHED_LDFLAGS needs to be added to memcache_store_la_LDFLAGS as it contains the -L flag to allow the linker to find the libmemcached .so file:

memcache-store/Makefile.am

Indeed, changing this and running autoreconf allowed the entire build to complete successfully again.

I've only looked at memcache-store, but looking at configure.ac it seems like the FastCGI support has the exact same logic as the memcached support in configure.ac, and may therefore exhibit the same issue of the required includes not being there during the header presence check. Additionally, fastcgi/Makefile.am includes the following lines:

Since FASTCGI_INCLUDE already includes the -I prefix though, I suspect that the final command line will end up with something like this (unverified):

As a final issue unrelated to the above, while pouring over configure.ac I found the following bit:

I think that should read:

As I said, I'm new to autotools, so feel free to point out if and where I'm wrong, or suggest better ways of doing things.

Environment

Red Hat Enterprise Linux Server release 5.9 (Tikanga)
autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.9.6

Attachments

3

Activity

Scott Cantor 
June 18, 2013 at 2:24 AM

Closing on release.

myhandisadolphin@mailinator.com 
June 16, 2013 at 10:19 PM
(edited)

Figured I might as well build and install FastCGI in a custom directory and try it. Extra configure flag:

Same thing as for memcached: ./configure can't find the header because the -I flag is added to CFLAGS and not CPPFLAGS, but once corrected, the build succeeds.

*EDIT: Slightly too late Thanks for your support Scott!

Scott Cantor 
June 16, 2013 at 10:03 PM

Corrected in r3866. Most of the C library tests are in one spot with gcc active, forgot to make that change. Easier to just use CPPFLAGS, which the ODBC check already did. Corrected same error in fastcgi test.

myhandisadolphin@mailinator.com 
June 16, 2013 at 9:51 PM
(edited)

Hi Scott,

Excellent response time!
I checked out the REL_2 branch and tested it, but unfortunately the libmemcached.h header presence check in ./configure still fails:

In your patch you added MEMCACHED_INCLUDE to CFLAGS; however, since g++ is being invoked, I think it needs to be added to CPPFLAGS instead. Once I change that, ./configure runs OK, and the build succeeds.

I didn't test the FastCGI part as I don't actually have it available to build against.

Scott Cantor 
June 16, 2013 at 6:53 PM

http://svn.shibboleth.net/view/cpp-sp?rev=3865&view=rev

Thank you for catching all that, literally last minute before tomorrow night's release.

I didn't do exactly what you suggested in every case, but there's no right or wrong, there are just a lot of inconsistent idioms in the code, same as every non-trivial configure script that's been around 10+ years.

If you have a chance to test before tomorrow night using the branch or by testing the patch rev above, it would be great.

Fixed

Details

Assignee

Reporter

Original estimate

Components

Fix versions

Affects versions

Created June 15, 2013 at 10:21 PM
Updated June 18, 2013 at 2:24 AM
Resolved June 16, 2013 at 6:53 PM