Odd issue with pod2man when building on Fedora build server

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> --- inn-2.5.2/storage/cnfs/cnfs.h.posix	2010-03-24 21:10:36.000000000 +0100
> +++ inn-2.5.2/storage/cnfs/cnfs.h	2010-06-28 17:33:11.106804964 +0200
> @@ -18,4 +18,12 @@ void cnfs_printfiles(FILE *file, TOKEN t
>  char *cnfs_explaintoken(const TOKEN token);
>  void cnfs_shutdown(void);
>  
> +/* Patch for POSIX  */
> +
> +#ifndef MADV_SEQUENTAL
> +  #ifdef POSIX_MADV_SEQENTIAL
> +    #define MADV_SEQUITIAL POSIX_MADV_SEQUENTIAL
> +  #endif
> +#endif
> +
>  #endif

> => I will have a look at this one.  Is there a specific architecture
> that needs this definition?

This change is only correct if the calls to madvise are also being changed
to posix_madvise.  I'm not sure why one would do that, though.  I suppose
we could do that more generally if posix_madvise is now more portable than
madvise or should be used by preference for portability, but that doesn't
seem like a change specific to a particular distribution.

This looks like a workaround for __USE_BSD not being defined during the
compilation, but INN should be built with GNU_SOURCE, which should enable
all the optional defines.  It so happens that MADV_SEQUENTIAL and
POSIX_MADV_SEQUENTIAL have the same value right now on Linux, but I don't
think that's something we should properly rely upon.

> --- inn-2.5.1/storage/buffindexed/ovmethod.mk.shared	2009-12-01 16:50:37.174811272 +0100
> +++ inn-2.5.1/storage/buffindexed/ovmethod.mk	2009-12-01 16:53:24.914809560 +0100
> @@ -1,8 +1,8 @@
>  # This rule requires a compiler that supports -o with -c.  Since it's normally
>  # used by developers, that should be acceptable.
> -buffindexed/buffindexed_d.o: buffindexed/buffindexed.c
> -	$(CC) $(CFLAGS) -DBUFF_DEBUG -c -o $@ buffindexed/buffindexed.c
> +buffindexed/buffindexed_d.$(EXTOBJ): buffindexed/buffindexed.c
> +	$(LIBCC) $(CFLAGS) -DBUFF_DEBUG -c -o $@ buffindexed/buffindexed.c

> => Do you have a specific need for shared libraries?

This is probably a correct change regardless, though.

> --- inn-2.5.1/frontends/Makefile.pie	2009-10-12 20:24:04.000000000 +0200
> +++ inn-2.5.1/frontends/Makefile	2009-10-13 21:51:38.000000000 +0200
> @@ -85,7 +85,7 @@ ovdb_init:	ovdb_init.o    $(BOTH)   ; $(
>  ovdb_monitor:	ovdb_monitor.o $(BOTH)   ; $(LINK) ovdb_monitor.o $(STORELIBS)
>  ovdb_server:	ovdb_server.o  $(BOTH)   ; $(LINK) ovdb_server.o  $(STORELIBS)
>  ovdb_stat:	ovdb_stat.o    $(BOTH)   ; $(LINK) ovdb_stat.o    $(STORELIBS)
> -rnews:		rnews.o        $(LIBINN) ; $(LINK) rnews.o        $(STORELIBS)
> +rnews:		rnews.o        $(LIBINN) ; $(LINK) rnews.o        -pie $(STORELIBS)
>  sm:		sm.o           $(BOTH)   ; $(LINK) sm.o           $(STORELIBS)

> => Is it necessary to add "-pie" for rnews?

I suspect this is because INN is setuid.  However, I don't think there's
any reason not to build all of INN with -fPIE -pie if that's what you want
(and likewise with other hardening flags), so I would just put that into
CFLAGS during configure time.

> => Be careful...  Makefile.global mentions:

> ##  DESTDIR should have a trailing slash, as the trailing
> ##  slash is not added automatically (in case someone wants to add a prefix
> ##  that isn't just a parent directory).

> DESTDIR         =
> D               = $(DESTDIR)

> so your patch normally should not add "/".  Anyway, as $(D) is $(DESTDIR),
> the patch is not necessary.

The comment is not really correct; the reason why the trailing slash isn't
required is because all the installation paths already start with /
because they're absolute paths determined by configure.  (It is true that
our build system doesn't correctly handle builds where the installation
paths are relative paths, but I'm not sure that anyone would ever do
that.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.