Re: GNU Autoconf 2.68 released [stable]

[Eric Blake]

[adding autoconf and bug-gnulib list, so others can chime in]

On 09/23/2010 09:12 AM, Bruce Korb wrote:
> Hi Eric,
>
> On Thu, Sep 23, 2010 at 4:52 AM, Eric Blake<address@hidden>  wrote:
> > ** Newly obsolete macros
> >    The following macros have been marked obsolete.  New programs
> >    should use the corresponding Gnulib modules.  Gnulib not only
> >    detects a larger set of portability problems with these functions,
> >    but also provides complete workarounds.
> >
> >      AC_FUNC_ERROR_AT_LINE  AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
> >      AC_FUNC_MKTIME  AC_FUNC_STRTOD
>
> Does this mean that autoconf and gnulib are now joined at the hip?

No, it means that autoconf will not do any further development on these 
macros (but they will continue to exist).  If you want a more up-to-date 
version of these macros, then use the macro from gnulib (licensing on m4 
macros in gnulib means the .m4 file can be used in any project); 
additionally, if you are in the position of being able to use LGPL or 
GPL .c files (depending on the module), then the gnulib implementation 
also serves as the way to provide the replacement files that was being 
requested by the AC_LIBOBJ() call buried in the autoconf version of 
these macros.

For example:

AC_FUNC_STRTOD requires that your package include a file named strtod.c 
that can serve as the replacement if the system's strtod() is missing or 
fails autoconf's tests.  Unfortunately, autoconf's tests are out-of-date 
(there are more portability bugs on modern targets, particularly with 
C99 compliance, that are not detected by the autoconf version of 
AC_FUNC_STRTOD).  And autoconf assumes that your replacement will 
require the use of pow(), so it adds POW_LIB to $(LIBS).  In contrast, 
the gnulib version of this macro is more complete for detecting a larger 
number of POSIX 2008 violations, as well as shipping a strtod.c that 
fixes all of those problems without using either pow() or -lm.

> If you are basically required to use gnulib in order to use autoconf
> and gnulib mostly seems to pre-suppose autoconf, then separating
> them seems not quite right.

No, you are not required to use gnulib.  The autoconf macro continues to 
exist, but it will not be updated to track newly-discovered portability 
issues.  And if you are worried about licensing, you can use the gnulib 
strtod.m4 without using the gnulib strtod.c, although the burden of 
writing a decent strtod.c then falls on your shoulders (but that is no 
different than it is if you use the autoconf macro).

> But that gets me back to gnulib and some outstanding questions.
> I can reverse engineer the results, but being told would surely be
> much easier:
>
> > > *** Warning: Linking the shared library libposix.la against the non-libtool
> > > *** objects  asnprintf.o [...] -Wl,-soname -Wl,libposix.so.0 -o 
> > > .libs/libposix.so.0.0.0
> > > /usr/bin/ld: asnprintf.o: relocation R_X86_64_32 against `a local symbol' can 
> > > not be used when \
> > > making a shared object; recompile with -fPIC
> > > asnprintf.o: could not read symbols: Bad value
> > > collect2: ld returned 1 exit status
> > > make[4]: *** [libposix.la] Error 1
> > > make[4]: Leaving directory 
> > > `/usr/local/src/gnulib/gnulib/libposix/libposix/libposix
>
> I took a peek at this.  The referenced .o objects get generated from
> being part of EXTRA_libposix_la_SOURCES and the members of
> libposix_la_SOURCES are compiled correctly.  I'd have expected
> that these sources would not actually get compiled at all.

How exactly are you using gnulib to add this macro into your project? 
I'm suspecting that the issue here is a matter of not using the tools in 
the optimal manner.  Also, remember that gnulib-tool has to be told 
whether you are using libtool or not, since it generates different 
Makefile.am snippets according to whether libtool is known to be in the mix.

> But there is some magic here.
>
> We have:
>    EXTRA_SOURCES
>    libposix_la_SOURCES
>    EXTRA_libposix_la_SOURCES
>
> The names in the first are simply rolled into the distribution tarball.
> The second get built into the shared object that is to be installed.
> The third get compiled non-PIC and an attempt is made to link
> them into the shared object, too.  Libtool doesn't like it.  I don't
> either.  Should these be EXTRA_SOURCES or libposix_la_SOURCES?
>
> ========= I have thought about it a bit more, but written no more code :
>
> It seems like, in the end, I need to configure some AM_CONDITIONALS for
> each gnulib module that gets imported and use that to generate alternate
> Makefile.am code.  In other words, something like this:
>
> > ## begin gnulib module areadlink
> > libgnu_a_SOURCES += areadlink.c
> > EXTRA_DIST += areadlink.h
> > ## end   gnulib module areadlink
>
> instead becomes:
>
> ## begin gnulib module areadlink
> if NEED_AREADLINK
> libgnu_a_SOURCES += areadlink.c
> EXTRA_DIST += areadlink.h
> else
> EXTRA_DIST += areadlink.[ch]
> endif
> ## end   gnulib module areadlink
>
> but since NEED_AREADLINK is not currently a conditional and since
> there is no guaranteed mapping between modules and any configure
> test result name, it would mean annotating each and every one of the
> posix modules, likely adding a section or two to the module definition.
>
> That's a lot of work.  I'd like to know that there's something easier.

I'm not sure how you are getting to this point.  Can you show the exact 
sequence of commands you used to try and import the gnulib module into 
your project?  And hopefully it was by using gnulib-tool, if you are 
grabbing anything more than just a single .m4 file.

> Thank you for your feedback!  Regards, Bruce

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org