[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<eblake@xxxxxxxxxx> 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 eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
