ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Code:
$ 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:
Code:
$ 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
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
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:
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
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:
Quote:
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 '.').
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
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
i have used this on a few of my things even to re-make old termcap "new". it makes a project for you: it makes the AM_FOO and config.ac and etc all that.
it looks at a "minimal" .c or .cpp project, fills in some templates, and runs autotools appropriately to make a bin or .so or .a (it can't do everything, no), includes distributing files and make check and make dist.
it's not "perfect" but on a small .c -> a.out or .c->a.so project you can read the short script "autoproj" to see what it does.
because it's automated the script, reading it tells you what you need to decide to do as well
i could not find a gnu termcap that made termcap.so.2 that was not distro-packaged, so i made this. i gnu what to make hack but didnt know how to start an autool project from scratch and wanted to record the process, and the recording of it is the script "autoproj".
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
