Hi Chris, * Chris Pickett wrote on Tue, Dec 23, 2008 at 07:00:08AM CET: > > I'm trying to use AC_REPLACE_FUNCS to provide strsignal. However, when > I run make it doesn't build a strsignal.lo for me, and libtool complains > "link: `strsignal.lo' is not a valid libtool object". This is using the > latest versions of the Autotools on MinGW/MSYS.
Hmm. I can only say "works for me", see the example below. > The Automake manual says, "The AC_CONFIG_LIBOBJ_DIR tells Autoconf that > the source files of these object files are to be found in the lib/ > directory. Automake can also use this information, otherwise it expects > the source files are to be in the directory where the ‘$(LIBOBJS)’ and > ‘$(ALLOCA)’ variables are used." > > My problem is that I do have the strsignal.c source in the same > directory as the src/Makefile.am but it isn't apparently getting built. > Is this an Automake bug or is it my fault, and if it is my fault, what > am I doing wrong? Relevant files/file snippets follow. Not sure; please compare what you are doing differently. > Side question: is the form of strsignal.c correct? For example, is the > strsignal prototype in the right place? I'm a bit sleepy / confused. Looks OK to me. To use it in other files, you may want to declare it in a header though. To ensure you use the system declaration (and definition) if available you should be including string.h and defining _GNU_SOURCE. Cheers, Ralf mkdir src cat >configure.ac <<\END AC_INIT(a,1) AM_INIT_AUTOMAKE(foreign) AC_CONFIG_FILES(Makefile src/Makefile) AC_PROG_CC AC_PROG_LIBTOOL AC_REPLACE_FUNCS([strsignal]) AC_OUTPUT END echo 'SUBDIRS = src' > Makefile.am cat >src/Makefile.am <<\END libcheck_la_LIBADD = @LTLIBOBJS@ libcheckinternal_la_LIBADD = @LTLIBOBJS@ lib_LTLIBRARIES = libcheck.la libcheckinternal.la END touch src/libcheck.c src/libcheckinternal.c autoreconf -vif # will error out unless src/strsignal.c exists ./configure ac_cv_func_strsignal=no # to fake nonexistent function make # will build and link strsignal.lo
