Odd issue with pod2man when building on Fedora build server

[Russ Allbery]

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

> So in fact if include/portable/mmap.h uses posix_madvise, if available.
> Which means changing:

> #if HAVE_MADVISE
> # define madvise(p, l, o)       madvise((void *)(p), (l), (o))
> #else
> # define madvise(p, l, o)       /* empty */
> #endif

> to:

> #if HAVE_MADVISE
> # ifndef MADV_SEQUENTIAL
> #  ifdef POSIX_MADV_SEQUENTIAL
> #   define madvise(p, l, o)     posix_madvise((void *)(p), (l), (o))
> #  else
> #   define madvise(p, l, o)     madvise((void *)(p), (l), (o))
> #  endif
> # else
> #  define madvise(p, l, o)      madvise((void *)(p), (l), (o))
> # endif
> #else
> # define madvise(p, l, o)       /* empty */
> #endif

> or something else that does not depend on MADV_SEQUENTIAL?

> Maybe it is wisest not changing anything about that and going on with the
> current code.

It doesn't seem horribly beneficial to try to change, although I will note
that the posix_madvise API is supposed to be more portable in the long run
and I think our usage fits entirely within that API.  If we were to make
this change, though, we should change all the calls in INN to be
posix_madvise and use the POSIX_* constants, and then use portable/mmap.h
to rewrite those to madvise and the MADVISE_* constants on platforms
without the POSIX interface (following the normal INN coding convention of
using the most standard interface by default and then fixing it up behind
the scenes).

>> 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.

> Besides, the patch for Fedora does not currently work because of typos in
> the names:  MADV_SEQUENTAL, POSIX_MADV_SEQENTIAL, MADV_SEQUITIAL.

Ah, I missed that.  So clearly the patch wasn't actually needed.  There's
a lot of other things to work on, so I'm dubious whether it's worth doing
the conversion mentioned above unless someone has problems.

>>> --- 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.

> Would it be useful to have it in upstream?

Yes.  Basically, there's no reason not to build the debugging version so
that it can be included in a shared library if desired.

>> 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.

> Isn't there a risk that building with '-fPIE -pie' introduces
> instability at runtime?  I read at
> <https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags>
> that some code does not function properly when PIE is used.  Probably
> code that is position-dependant, but how can we be sure that no part of
> INN uses that?

My experience is that you'll know if this happens, since the binary will
exit immediately with a bus error when run.  I build all my packages for
Debian with PIE by default now, and have only run into one package (GNU
Backgammon) that didn't work, and I suspect that's because it has some
assembly for speeding up some parts of the game engine.  If you're writing
straight C and not doing anything exciting, PIE really should work.

-- 
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.