svn commit: samba r22731 - in branches/SAMBA_3_0/source: . tests

[derrell at samba.org]

"Stefan (metze) Metzmacher" <metze at samba.org> writes:

> derrell at samba.org schrieb:
>> Author: derrell
>> Date: 2007-05-07 03:02:24 +0000 (Mon, 07 May 2007)
>> New Revision: 22731
>> 
>> WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=22731
>> 
>> Log:
>> 
>> - Fix bug #4594.
>>   
>>   configure.in determines if -Werror-implicit-function-declaration is
>>   available, and if so it enables that flag if --enable-developer is
>>   specified.  Since the configure tests themselves did not use that flag, it
>>   was possible for a configure test to succeed, followed by a failed
>>   compilation due to a facility being available but not having a proper
>>   declaration in a header file.  (This bit me with readahead().)  This patch
>>   ensures that if implicit function declarations will kill the build, the
>>   feature being tested is deselected so the build will succeed.
>> 
>>   The autoconf manual suggests using return instead of exit in configure
>>   tests because the declaration for exit is often missing.  We require this
>>   now, since we error if prototypes are missing.  See section 5.5.1 of
>>   http://www.gnu.org/software/autoconf/manual/autoconf.html.  This patch makes
>>   these changes, because in fact, an external declaration for exit is missing
>>   here (and likely elsewhere).
>> 
>>   I've verified that the features selected (here) with the original
>>   configure.in and the new one are the same except for, in my case,
>>   readahead.  I've also confirmed that the generated Makefile is identical.
>> 
>>   These changes are not being applied to the 3.0.26 branch because it does not
>>   exhibit the initial problem this patch is supposed to solve since it doesn't
>>   attempt to use -Werror-implicit-function-declaration.
>
> Hi Derell,
>
> I don't think it's correct to use -Werror-implicit-function-declaration
> within the configure checks. Because the configure result now may
> differs between the normal and developer build.

Yes, that's exactly what I want (need) to do.  The configure tests must differ
between the builds so that functions which are available during a
non-developer build will be used, whereas functions that will cause the
compile to barf during a developer build are excluded during a developer
build.

> The correct fix would be to use a AC_CHECK_DECL() or AC_HAVE_DECL()
> for the specific function.

The problem is that these macros use whatever CFLAGS are defined.  If
-Werror-implicit-function-declaration is not defined in CFLAGS during
configure, configure will determine that a function is available when in fact,
during a compile with -Werror-implicit-function-declaration, the compile will
fail.  I don't think it's appropriate for configure to decide a feature should
be used when using it causes the compile to barf.  This is exactly the case I
encountered.  readahead() is available on my system, but is not declared in a
header file, similarly to exit().  Without that flag, a developer configure
will determine that readahead() is available but a compile will fail.  By
consistently testing for and using the warnings-are-errors flag, the problem
is eliminated.  During a developer build, readahead() is found to _not_ exist
so the compilation works fine.  During a production build, readahead() is
found to exist and the compilation works fine since it doesn't use the
warnings-are-errors flag.

Derrell