Odd issue with pod2man when building on Fedora build server

[Julien ÉLIE]

Hi Russ,

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

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.



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



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



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

-- 
Julien ÉLIE

« Et maintenant nous sommes roulés. » (Astérix)