Re: gnulib taking over libobjs?

[Simon Josefsson]

address@hidden (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