[greenstone-devel] Configure Problems

From Kurt Baker
DateFri, 03 Dec 2004 16:21:18 -0500
Subject [greenstone-devel] Configure Problems

Hello Greenstone developers:

           At the bottom of this mail message John McPherson suggested that I try to create a new configure.in with a new version of autoconf to solve a problem discovered during the configure process.  This indeed may be the source of the problem, but it requires some knowledge of autoconf.   

        We installed autoconf 2.59 and ran autoconf in the greenstone directory.   I received the following error message:

configure.in:169: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

The autoconf documentation follows, but I am wary of making changes to the configure.in file myself.  Any help would be appreciated.

Kurt Baker


Up to Autoconf 2.13, the replacement of functions was triggered via the variable LIBOBJS. Since Autoconf 2.50, the macro AC_LIBOBJ should be used instead (see section Generic Function Checks). Starting at Autoconf 2.53, the use of LIBOBJS is an error.

This change is mandated by the unification of the GNU Build System components. In particular, the various fragile techniques used to parse a `configure.ac' are all replaced with the use of traces. As a consequence, any action must be traceable, which obsoletes critical variable assignments. Fortunately, LIBOBJS was the only problem, and it can even be handled gracefully (read, "without your having to change something").

There were two typical uses of LIBOBJS: asking for a replacement function, and adjusting LIBOBJS for Automake and/or Libtool.

As for function replacement, the fix is immediate: use AC_LIBOBJ. For instance:

LIBOBJS="$LIBOBJS fnmatch.o"
LIBOBJS="$LIBOBJS malloc.$ac_objext"

should be replaced with:


When asked for automatic de-ANSI-fication, Automake needs LIBOBJS'ed filenames to have `$U' appended to the base names. Libtool requires the definition of LTLIBOBJS, whose suffixes are mapped to `.lo'. People used to run snippets such as:

# This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
LIBOBJS=`echo "$LIBOBJS" | sed 's/.o /$U.o
LTLIBOBJS=`echo "$LIBOBJS" | sed 's/.o/.lo/g'`

Note that this code is wrong, because `.o' is not the only possible extension(4)! It should have read:

# This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
LIB@&t@OBJS=`echo "$LIB@&t@OBJS" |
sed 's,.[[^.]]* ,$U&,g;s,.[[^.]]*$,$U&,'`
LTLIBOBJS=`echo "$LIB@&t@OBJS" |
's,.[[^.]]* ,.lo ,g;s,.[[^.]]*$,.lo,'`

You no longer have to use this: AC_OUTPUT normalizes LIBOBJS and LTLIBOBJS (hence it works with any version of Automake and Libtool). Just remove these lines (autoupdate cannot handle this task, since this is not a macro).

Note that U must not be used in your Makefiles.

> Hello Greenstone developers:
>       I am trying to install Greenstone from the source on Sun
> Solaris.  During the configure, I get an error at line 188 in the file
> config.cache.  It seems to be a syntax error in the sed command contained
> within the line.  I am not proficient with sed nor do I understand the
> developers intent.
>      Below is the line in question.  Any help will be appreciated.
> test "${lt_cv_global_symbol_to_c_name_address+set}" = set ||
> lt_cv_global_symbol
> _to_c_name_address=$'sed -n -e 's/^: \([^ ]*\) $/  {\"\1\", (lt_ptr)
> 0},/p
> ' -e 's/^[BCDEGRST] \([^ ]*\) \([^ ]*\)$/  {"\2", (lt_ptr) \&\2},/p''
> Thanks,
> Kurt Baker

that is a bit ugly... rest assured that those lines are not from a
greenstone developer, but automatically generated by the configure
script. The problem (as far as I can see, at least) is that you can't
escape a ' char inside '...' quotes, so '...'....' shouldn't work
on proper bourne shell.

I have no idea why the configure script is making bad shell code since
it is supposedly tested to be portable - I assume it is/was a bug
in a particular version of autoconf/autotools.

Perhaps you could try downloading a newer version of the autotools
package, and then running 'autoconf' in the greenstone directory to
generate a new 'configure' script from our configure.in, and see if
that fixes the problem - if so, let us know and we'll try to get it
fixed for future releases.

John McPherson

greenstone-devel mailing list

 Kurt Baker
 Digital Library Technologies
 E3 Paterno
 University Park, PA 16802
 phone: (814) 865-1818
 fax: (814) 863-3560
 email: kbb@psulias.psu.edu