[EMAIL PROTECTED] (Karl Berry) writes: > I finally started switching to standard gnulib usage in Texinfo. I did > gnulib-tool --import getopt gettext > for starters, did the requisite configure.ac and Makefile.am stuff. > > But then, rerunning automake gave me complaints like this: > gnulib/lib/Makefile.am:18: required file `gnulib/lib/strdup.c' not found > gnulib/lib/Makefile.am:18: required file `gnulib/lib/memmove.c' not found > ... > > These are functions which I had been replacing in my usual > program-specific lib, via: > AC_REPLACE_FUNCS(memcpy memmove strdup strerror) > > I see that the generated gnulib/lib/Makefile.am contains the line: > libgnu_a_LIBADD = @LIBOBJS@ > > So, all in all, it seems that gnulib assumes that it will be responsible > for anything and everything ending up in @LIBOBJS@, e.g., anything in > AC_REPLACE_FUNCS. Is this correct? (Or @LTLIBOBJS@ if libtool, I guess.)
Yes, unfortunately. This is the main problem with using the AC_LIBSOURCES and AC_REPLACE_FUNCS approach, which was introduced not too long ago. I recall that future autoconf/automake versions -- autoconf 3.0? -- would be able to solve this. > It's not exactly a problem as things stand -- of course I will use the > gnulib modules to get those functions. I'd like to add something to the > gnulib docs about it, though. That would be good, as this is a known limitation that is likely to hit people moving to gnulib for existing packages. > I imagine that a typical package xyz probably has gnulib stuff in, say, > gnulib/ and xyz-specific stuff in, say, lib/. So AC_REPLACE_FUNCS > can't be used for anything in lib/ ? This isn't a problem? It's a hassle for me, but not major. /Simon
