bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: installable gnulib library


From: Gary V. Vaughan
Subject: Re: installable gnulib library
Date: Sun, 10 Oct 2010 16:14:54 +0700

Hi Bruce, Bruno,

On 10 Oct 2010, at 03:25, Bruce Korb wrote:
> May I push the script as it can have no effect without someone
> explicitly running it?
> Attached is another copy, different from the last only in that datarootdir was
> added to the generate-libtool.pc-script.

I think your script is *much* more complicated than it needs to be. Far easier 
to let the existing gnulib machinery populate an installable libposix project, 
surely? See below for my alternative two line script =)O|

It occurs to me also, that when another gnulib using project (that relies on 
non-libposix modules) wants to minimise it's configury by requiring libposix, 
gnulib-tool will need an --avoid-posix option or similar so as not to end up 
pulling another copy of the posix modules and their dependencies into the new 
project.

Also, while I understood why it was done at the time, the future of a 
comprehensive libposix looks bleak when fnmatch-posix, memset, strcspn and 
other arguably dangerous, but none-the-less posix specified api functions are 
marked as obsolete.  I'd have a lot more confidence in a gnulib based libposix 
if those functions were marked instead as deprecated with a pointer to the 
better alternative.  Obsolete suggests that support is going away.

The following works for me, by placing the following files in their own 
directory and running bootstrap -- barring a handful of small bugs in gnulib 
that we can fix:

# bootstrap:

#!/bin/sh
gnulib-tool --import --lib=libposix --source-base=libposix --libtool 
--with-tests `posix-modules`
autoreconf -fvi


## Makefile.am:

ACLOCAL_AMFLAGS = -I m4
SUBDIRS = libposix tests


## configure.ac:

AC_INIT([libposix], [20101010], address@hidden)
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile libposix/Makefile tests/Makefile])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign])
LT_INIT
AC_PROG_CC
gl_EARLY
AM_PROG_CC_C_O
gl_INIT
AC_OUTPUT


2 bugs need fixing for this to work as intended:

1. posix-modules vs strdup
--------------------------
The posix-modules script outputs both 'strdup' and 'strdup-posix' causing a 
warning: 'This module is obsolete. But you may want to use the strdup-posix 
module.'. I had to filter the out put of posix-modules to use omit strdup to 
prevent that.

2. posix-modules vs alloca
--------------------------
The modules specified by posix-modules require an LTALLOCA definition, per 
'libposix/Makefile.am:35: @LTALLOCA@ used but `LTALLOCA' is undefined'.  So I 
had to add the alloca module to the gnulib-tool invocation in bootstrap above.

That feels like a kludge to me.  If the posix-modules require alloca, shouldn't 
it have been added?  Or perhaps this is telling me that all of the modules that 
have been added to libposix need auditing for alloc-die() and the like, to make 
sure the library returns an error rather than aborting?

3. missing AM_CONDITIONAL declarations
--------------------------------------
I suppose the following definitions are supposed to have been added to gl_INIT 
somewhere, but `git grepping' around the gnulib sources didn't lead me to the 
culprit.

libposix/Makefile.am:4192: LIBUNISTRING_COMPILE_UNISTR_U8_MBTOUCR does not 
appear in AM_CONDITIONAL
libposix/Makefile.am:4200: LIBUNISTRING_COMPILE_UNISTR_U8_UCTOMB does not 
appear in AM_CONDITIONAL
libposix/Makefile.am:4240: LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH does not appear 
in AM_CONDITIONAL

To work around it for now, I've temporarily added 
AM_CONDITIONAL([LIBUNISTR....], [false]) declarations to the configure.ac file 
above... which is almost certainly wrong, but does at least allow the library 
to build.

4. pt_chown module
------------------
gnulib/modules/pt_chown hardcodes libgnu.a, so I had to edit the gnulib 
generated libposix/Makefile.am in libposix to refer to libposix.la instead.


5. AC_USE_SYSTEM_EXTENSIONS references
--------------------------------------
This is just a warning, and doesn't prevent compilation so I didn't try to 
figure out exactly how to fix a series of these warnings:

configure.ac:12: warning: AC_COMPILE_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was 
called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top levelconfigure.ac:12: warning: AC_COMPILE_IFELSE was 
called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was 
called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top level

The following is probably instructive:

; grep -l AC_COMPILE_IFELSE `grep -l AC_RUN_IFELSE m4/*` \
  | xargs grep -l AC_USE_SYSTEM_EXTENSIONS
m4/extensions.m4
m4/glob.m4

2 matching files for 2 sets of warnings, so likely these 2 are the culprits.

I did try adding AC_USE_SYSTEM_EXTENSIONS to configure.ac right after AC_INIT, 
but oddly the warnings remain.  I hope this isn't an AC_REQUIRE bug :(


Cheers,
-- 
Gary V. Vaughan (address@hidden)

Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]