[PATCH] #ifdef code cleanup

Martin Schwenke martin at meltin.net
Fri Nov 30 06:31:30 UTC 2018


On Fri, 30 Nov 2018 16:57:35 +1100, Martin Schwenke via samba-technical
<samba-technical at lists.samba.org> wrote:

> On Fri, 30 Nov 2018 15:13:30 +1100, Martin Schwenke via samba-technical
> <samba-technical at lists.samba.org> wrote:
> 
> > On Thu, 29 Nov 2018 08:38:06 +0100, Andreas Schneider <asn at samba.org>
> > wrote:
> >   
> > > On Thursday, 29 November 2018 08:00:39 CET Martin Schwenke wrote:  
>  [...]  
>  [...]  
> > >  [...]    
>  [...]  
>  [...]  
> > > 
> > > According to the manpage, this is provided by unistd.h. So the attached patch 
> > > should fix this. Could you please check?  
> > 
> > Yep, looks good, fixes the build.
> > 
> > Reviewed-by: Martin Schwenke <martin at meltin.net>
> > 
> > Pushed...  
> 
> Hmmm... I've pulled the autobuild because this now falls over on AIX:
> 
> "/usr/include/unistd.h", line 201.17: 1506-343 (S) Redeclaration of lseek64 differs from previous declaration on line 199 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 201.17: 1506-050 (I) Return type "long long" in redeclaration is not compatible with the previous return type "long".
> "/usr/include/unistd.h", line 201.17: 1506-377 (I) The type "long long" of parameter 2 differs from the previous type "long".
> "/usr/include/sys/lockf.h", line 64.20: 1506-343 (S) Redeclaration of lockf64 differs from previous declaration on line 62 of "/usr/include/sys/lockf.h".
> "/usr/include/sys/lockf.h", line 64.20: 1506-377 (I) The type "long long" of parameter 3 differs from the previous type "long".
> "/usr/include/unistd.h", line 920.33: 1506-343 (S) Redeclaration of ftruncate64 differs from previous declaration on line 918 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 920.33: 1506-377 (I) The type "long long" of parameter 2 differs from the previous type "long".
> "/usr/include/unistd.h", line 977.33: 1506-343 (S) Redeclaration of truncate64 differs from previous declaration on line 975 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 977.33: 1506-377 (I) The type "long long" of parameter 2 differs from the previous type "long".
> "/usr/include/unistd.h", line 996.33: 1506-343 (S) Redeclaration of pread64 differs from previous declaration on line 993 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 996.33: 1506-377 (I) The type "long long" of parameter 4 differs from the previous type "long".
> "/usr/include/unistd.h", line 997.33: 1506-343 (S) Redeclaration of pwrite64 differs from previous declaration on line 994 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 997.33: 1506-377 (I) The type "long long" of parameter 4 differs from the previous type "long".
> "/usr/include/unistd.h", line 1086.25: 1506-343 (S) Redeclaration of fclear64 differs from previous declaration on line 1083 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 1086.25: 1506-050 (I) Return type "long long" in redeclaration is not compatible with the previous return type "long".
> "/usr/include/unistd.h", line 1086.25: 1506-377 (I) The type "long long" of parameter 2 differs from the previous type "long".
> "/usr/include/unistd.h", line 1087.25: 1506-343 (S) Redeclaration of fsync_range64 differs from previous declaration on line 1084 of "/usr/include/unistd.h".
> "/usr/include/unistd.h", line 1087.25: 1506-377 (I) The type "long long" of parameter 3 differs from the previous type "long".
> 
> Trying to understand this...

Sorry, the above error message was incomplete.

It was falling over in the CTDB standalone build on AIX (we don't do a
full Samba build on AIX, so I didn't notice quickly enough), in
lib/util/strv_util.c. This file seems to have been unique due to the
stupid include order used there by the author (me). Me encountering
problems due to that is obviously known as karma.  ;-)

I've attached a fix for that.  Please review and maybe push ahead of
your patch, which is still:

Reviewed-by: Martin Schwenke <martin at meltin.net>

I've confirmed the CTDB standalone build is fixed (on AIX, and
Linux/FreeBSD) and the full Samba build is still OK (on Linux/FreeBSD).

Thanks...

peace & happiness,
martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-util-Fix-include-file-order.patch
Type: text/x-patch
Size: 730 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20181130/5d6a7bce/0001-util-Fix-include-file-order.bin>


More information about the samba-technical mailing list