Artsize still not quite right in CURRENT

[James Ralston]

On Thu, 19 Apr 2001, Joe St Sauver wrote:

> Addinng -D_XOPEN_SOURCE=500 to inn-CURRENT-20010417's
> Makefile.global results in the error:
>
> gcc -g -O2 -I../include  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -c date.c
> date.c: In function `local_tz_offset':
> date.c:66: structure has no member named `tm_gmtoff'
> date.c: In function `makedate':
> date.c:160: structure has no member named `tm_zone'
> make[1]: *** [date.o] Error 1

This occurs because you didn't run configure with CC set to
"gcc -D_XOPEN_SOURCE=500".  The configure script must use the same
feature-test macros which will be used for the actual compilation, or
else the state of the system it detects won't represent the actual
state of the system at compile-time.

You're correct, however; the build step will still bomb out.  The
reason that happens is because parts of INN use BSD-isms (the u_short,
u_int, et. al. typedefs), and glibc's BSD features aren't
automatically included if any of the feature-test macros are defined.
(The logic here seems to be that if you've used the feature-test
macros, you probably know enough to turn on the specific features that
you want.)

The solution is to make sure the BSD features are included:

    CC="gcc -D_XOPEN_SOURCE=500 -D_BSD_SOURCE"; export CC
    ./configure
    make

That works; I just tested a full build with it.

On 19 Apr 2001, Russ Allbery wrote:
> Yup, this is exactly why I dislike feature-test macros.  *sigh*

There's a certain amount of irony here, I think: INN (as it currently
stands) is an argument *for* feature-test macros.

If I try to compile inn-CURRENT-20010417 thusly:

    CC="gcc -D_GNU_SOURCE"; export CC
    ./configure
    make

It bombs out:

    make[1]: Entering directory `/tmp/RPM/BUILD/inn-CURRENT-20010417/lib'
    gcc -D_GNU_SOURCE -O2 -march=i386 -mcpu=i686 -I../include   -c daemonize.c
    In file included from daemonize.c:21:
    ../include/libinn.h:137: parse error before `64'

Why?

Here's the snippet from include/libinn.h in question:

    /*
    **  FILE LOCKING
    */
    enum locktype {
        LOCK_READ,
        LOCK_WRITE,
        LOCK_UNLOCK
    };

But /usr/include/bits/fcntl.h has:

    #ifdef __USE_GNU
    # define LOCK_MAND  32  /* This is a mandatory flock:   */
    # define LOCK_READ  64  /* ... which allows concurrent read operations.
    # define LOCK_WRITE 128 /* ... which allows concurrent write operations.
    # define LOCK_RW    192 /* ... Which allows concurrent read & write oper
    #endif

This is INN's fault: it has poorly-chosen names for its own private
symbols, and they clash with the C library *when all functionality of
the C library is available*.  INN has directly benefited from the
glibc maintainers' decision to not make all symbols/functionality
available unless specifically requested via feature-test macros.

I suspect this is why the glibc maintainers implemented the
feature-test macros.  As more functionality is added to the C library,
and more symbols are defined, the chances of clashes with programs
that were written before those symbols were defined increases.  If
INN--which is under active maintenance and development--has symbol
clashes with the complete functionality of glibc, what chance do the
hundreds (if not thousands) of programs and packages which *aren't*
being actively maintained have to avoid symbol clashes?  If every new
symbol or piece of functionality added to glibc were automatically
visible, the number of older programs that would clash with those
symbols might be so great as to cause people to refuse to upgrade
glibc.

> The hope is that _GNU_SOURCE won't do that.  Hm.  Okay, I agree that
> it's probably the best workaround that we have; now I wonder if
> there's a good way to put logic in configure.in so that it only adds
> it if it's necessary.

That's easy.  This patch is against CURRENT-20010420:

--- configure.in.old	Fri Apr 20 05:00:04 2001
+++ configure.in	Fri Apr 20 18:20:49 2001
@@ -90,4 +90,16 @@
 AC_SUBST(UPLIBTOOLLD)

+dnl If this is a glibc system, we need to define _GNU_SOURCE in order
+dnl to make all symbols/functionality of glibc visible.  Conditionally
+dnl defining _GNU_SOURCE in include/config.h won't cut it; all of the
+dnl configure tests need to be carried out with _GNU_SOURCE defined as
+dnl well.  We rely on checking for the gnu_get_libc_version symbol
+dnl (thanks Fabien) instead of trying to look at the files in /lib or
+dnl /usr/lib; what matters is what libc the compiler's using, and the
+dnl best way to test that is to let the compiler look for the symbol.
+AC_CHECK_FUNC(gnu_get_libc_version,
+  CC="${CC-cc} -D_GNU_SOURCE"
+)
+
 dnl INN has quite a few more configurable paths than autoconf supports by
 dnl default.  For right now, those additional paths are configured with

INN's symbol clashes with the complete functionality of glibc need to
be resolved, of course.  If no one else wants to volunteer to do this,
I'll go ahead and do it; I've already spent a fair amount of time
poking at glibc and INN...

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA