first library with autotools / libtool

Hi. I created my first tiny C library yesterday. I can build it fine using manual gcc commands, but I'm having trouble getting it integrated with autotools and libtool.

When I run "autoreconf" I get this:

$ autoreconf
Makefile.am:1: variable `librremove_@EXAMPLE_API_VERSION@_la_SOURCES' is defined but no program or
Makefile.am:1: library has `librremove_@EXAMPLE_API_VERSION@_la' as canonical name (possible typo)
Makefile.am:2: variable `librremove_@EXAMPLE_API_VERSION@_la_LDFLAGS' is defined but no program or
Makefile.am:2: library has `librremove_@EXAMPLE_API_VERSION@_la' as canonical name (possible typo)

Here is my configure.ac, which I made trying to follow some online tutorials:

$ cat configure.ac
#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_INIT([Recursive Remove], [0.3.1], [christopher.howard@frigidcode.com],
        [rremove], [http://frigidcode.com/code/rremove/])
AC_PREREQ([2.68])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_HEADERS([config.h])
AC_PROG_CC

LT_INIT
AC_SUBST([EXAMPLE_SO_VERSION], [0:0:0])
AC_SUBST([EXAMPLE_API_VERSION], [0.0])

AC_CONFIG_SRCDIR([rremove.c])
AC_CONFIG_FILES([Makefile])

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_OUTPUT

Likewise, my Makefile.am:

$ cat Makefile.am 
librremove_@EXAMPLE_API_VERSION@_la_SOURCES = rremove.c
librremove_@EXAMPLE_API_VERSION@_la_LDFLAGS = -version-info $(EXAMPLE_SO_VERSION)
librremove_@EXAMPLE_API_VERSION@_la_CFLAGS = -Wall -Wextra -pedantic -std=c99
rremove_includedir = $(includedir)
nobase_rremove_include_HEADERS = rremove.h

Evidently I missed some important concept along the way. Can someone point me in the right direction?

I don't think you can do that sort of substitution within variable names; it confuses libtool. Normally you would use lib_LTLIBRARIES=librremove.la, then librremove_la_SOURCES=..., and libtool will take care of numbering the .so at install time based on the -version-info. It looks like you're trying to put Makefile.in stuff in the Makefile.am, but the Makefile.am must be understandable by libtool before the Makefile.in can be created.

Also, have you run libtoolize? I always get confused about what to run and in which order, so I usually run automake, autoconf, and aclocal repeatedly until it works (taking care of warnings if they come up.) Not the best way to do it, but once you get it running for a project it's no work to add new things to the project (which is why I'm not all that skillful the initial setup.)
Kevin Barry

Originally Posted by ta0kira I don't think you can do that sort of substitution within variable names; it confuses libtool. Normally you would use lib_LTLIBRARIES=librremove.la, then librremove_la_SOURCES=..., and libtool will take care of numbering the .so at install time based on the -version-info. It looks like you're trying to put Makefile.in stuff in the Makefile.am, but the Makefile.am must be understandable by libtool before the Makefile.in can be created. Also, have you run libtoolize? I always get confused about what to run and in which order, so I usually run automake, autoconf, and aclocal repeatedly until it works (taking care of warnings if they come up.) Not the best way to do it, but once you get it running for a project it's no work to add new things to the project (which is why I'm not all that skillful the initial setup.) Kevin Barry

What I did to fix the problem (before you posted) was I switched to a different tutorial and ended up with a Makefile.am more like this:

lib_LTLIBRARIES = librremove.la
     librremove_la_SOURCES = rremove.c
     librremove_la_LDFLAGS = -version-info 0:2:0
     librremove_la_CFLAGS = -Wall -Wextra -pedantic -std=c99
rremove_includedir = $(includedir)
nobase_rremove_include_HEADERS = rremove.h

And got rid of the AC_SUBST junk in the configure.ac. (Of course, I properly increment the version-info according to instructions.) So far, this is working great. Not sure now what the API_VERSION junk was about. I don't really care much about SO_VERSION variable substitution because it seems just as easy to edit the Makefile.am for this, though I suppose there might be a problem down the road if I expand to multiple directories.

The -version-info should be specific to each .la because the resulting numbering will affect which library a new program is linked to (if multiple versions are installed.) That means it should probably be set within Makefile.am exactly where you have it, rather than in configure.ac. The reasoning is that if you're changing the library enough to change the version then you're probably messing around in it's source directory, anyway. I use autotools for a project with 27 libraries and it's helpful to change the version in the same place I change the source, but it can also be a pain if you have to change the versions of several libraries at the same time (e.g. a large set of plug-ins with comparable interfaces.)
Kevin Barry

Originally Posted by ta0kira Also, have you run libtoolize? I always get confused about what to run and in which order, so I usually run automake, autoconf, and aclocal repeatedly until it works

That's what autoreconf is for:

man autoreconf(1) ... Run 'autoconf' (and 'autoheader', 'aclocal', 'automake', 'autopoint' (formerly 'gettextize'), and 'libtoolize' where appropriate) repeatedly to remake the GNU Build System files in specified DIRECTORIES and their subdirectories (defaulting to '.').

Originally Posted by ntubski That's what autoreconf is for:

I've never actually looked at that manpage. Apparently I have the same functionality as autoreconf...
Kevin Barry

Originally Posted by ta0kira The -version-info should be specific to each .la because the resulting numbering will affect which library a new program is linked to (if multiple versions are installed.) That means it should probably be set within Makefile.am exactly where you have it, rather than in configure.ac. The reasoning is that if you're changing the library enough to change the version then you're probably messing around in it's source directory, anyway. I use autotools for a project with 27 libraries and it's helpful to change the version in the same place I change the source, but it can also be a pain if you have to change the versions of several libraries at the same time (e.g. a large set of plug-ins with comparable interfaces.) Kevin Barry

27 libraries?? What project is that?

Originally Posted by hydraMax 27 libraries?? What project is that?

Almost all of them are plug-ins. It's a personal project that unfortunately outpaced my ability to document it. Realistically, I need to merge about 8 of them into 1, but there's only one that needs to be linked to by someone using the project. It's mostly been for the purposes of my own learning for the last 5 years, with some possible practical uses for me in the future.
Kevin Barry