Hi Reuben, On 31 Jan 2013, at 00:37, Reuben Thomas <r...@sc3d.org> wrote: > On 30 January 2013 17:10, Gary V. Vaughan <g...@gnu.org> wrote: >> Are you using the bootstrap script from gnulib (which I didn't check) > > Yes.
Then, may I humbly suggest you switch to my bootstrap rewrite, which has behaviour the two of us at least are considerably more familiar with? >> Similarly there is no code in bootstrap rewrite to override the default >> setting of --lib, save setting gnulib_name=lib$package in bootstrap.conf. >> Bootstrap rewrite is extremely configurable, so maybe you are overwriting >> setting gnulib_name somehow from bootstrap.conf? > > Nope, it's the default, commit a1c6bc99 by Jim Meyering back in 2007: > > gnulib_name=lib$package That seems entirely wrong to me. If I have a package, say GNU m4, then libm4 is a library built and installed by my package. Why on earth would I want gnulib to stomp all over my namespace? At least there is a straight forward work around: In your gnulib bootstrap using package, always set: gnulib_name=libgnu > (in build_aux/bootstrap). >> >> Quickly testing latest gnulib-tool, it already shows a reminder to set >> _LDADD or _LDFLAGS appropriately. It seems your environment is not working >> properly. > > It does tell me to set those variables for example for LIBINTL, and for other > variables that gnulib modules may set, like LIB_PTY, but it doesn't mention > the gnulib library, libfoo.a (where $PACKAGE=foo). Agreed, I missed that, sorry. It seems like a simple oversight though, and I'm sure a patch would be welcome. Adding something along the lines of the following after line 5500 or so of gnulib-tool should do the trick: echo echo "You will need to ensure any libraries or programs that may use entry points" echo "from $libname.$libext are linked against it correctly by adding $libname.$libext" echo "to <program>_LDADD or <library>_a_LDFLAGS or <library>_la_LDFLAGS as" echo "appropriate." Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
