You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <Ma...@Fujitsu-Siemens.com> on 2001/01/30 09:17:57 UTC
Re: APACHE20 problem with string.h and strings.h
On Mon, Jan 29, 2001 at 06:50:01PM +0100, jean-frederic clere wrote:
> Hi Martin,
>
> I have tried APACHE20 on the SVR4 MACHINE and the compilation fails:
> It appears that APR detects that bzero, bcopy and bcmp are not supported
> (ucb), and tries to replace them. But it also includes strings.h that
> contains their definition.
> For example:
> httpd-2.0/srclib/apr/tables/apr_tables.c
> +++
> #ifdef
> HAVE_STRING_H
> #include <string.h>
> #endif
> #if
> APR_HAVE_STRINGS_H
> #include <strings.h>
> #endif
> +++
>
> The problem occurs like that:
> bzero is defined as memset(void *,0, size_t) in
> httpd-2.0/srclib/apr/include/apr_general.h
> Of course when strings.h is included the compilation fails...
>
> What is the solution:
> - use /usr/ucb/cc? - I do not like it -
> - Add -lucb to the libraries? - I am afraid APR should be the tool to
> avoid this kind of libraries.
> - Try to fix the problem in APACHE, why do we include strings.h if we
> try to emulate the routines that are inside?
>
> Any comments? Before I try to explain the 3d solution to new-httpd
I don't see the necessity for such a strict logical separation between
string.h and strings.h as it is traditionally existing in SVR4.
In SVR4, strings.h in "the berkeley (ucb) functions" and string.h
is "the at&t (sysv) functions".
But that need not be the case for other OS's. Look at FreeBSD: though
it is BSD-derived, all it has in <strings.h> is:
/* ...
* @(#)strings.h 8.1 (Berkeley) 6/2/93
*/
#include <string.h>
But in <strings.h>, it protects the non-ASNI functions like this:
/* Nonstandard routines */
#if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE)
int bcmp __P((const void *, const void *, size_t));
void bcopy __P((const void *, void *, size_t));
void bzero __P((void *, size_t));
...
I think it is "the fault of" SVR4 that they integrated both environments
so poorly, and did not provide a way to exclude the non-ANSI definitions.
But back to your list:
> What is the solution:
> - use /usr/ucb/cc? - I do not like it -
Sometimes, this is the easiest way. It used to be a PITA back in the
beginning of SVR4 (SINIX-5.4x), but works quite well today with CDS++.
I ported httperf recently in a few minutes (and I remember it took me
hours a few years ago), and httperf is a very tricky application which
relies heavily on BSD'isms. OTOH, this is not BSD, it's SVR4, and I'd
prefer not to have to rely on the /usr/ucb/cc "emulation".
> - Add -lucb to the libraries? - I am afraid APR should be the tool to
> avoid this kind of libraries.
Right. But still, considering a "-lc -lucb" was the best SVR4 workaround
for years. It links against libc first, and only if something (rindex etc)
is still undefined, it resolves it from libucb. By using this order, you
avoid the traditional core dumps you get when mixing readdir() from libc
with the readdir() from libucb. But when apr supplies replacements anyway,
we should not have a need for libucb at all.
> - Try to fix the problem in APACHE, why do we include strings.h if we
> try to emulate the routines that are inside?
Now what causes the problem? IMO it's THE ORDER of includes. If apr were
to include the system headers <string*.h> FIRST, and THEN provide their
override, then nothing whatsoever would go wrong (even if they use different
const qualifiers than the system includes...).
And that's IMHO the way to go.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany
Re: APACHE20 problem with string.h and strings.h
Posted by jean-frederic clere <jf...@fujitsu.siemens.es>.
Jeff Trawick wrote:
>
> jean-frederic clere <jf...@fujitsu.siemens.es> writes:
>
> > Jeff Trawick wrote:
> > >
> > > I think I prefer dispensing with APR's definition of bzero()
> > > altogether. Why should APR be defining such a thing? (If it needed
> > > to provide such a thing, it should be called apr_something(). I'll
> > > suggest on the APR list removing the bzero mapping altogether.
> >
> > Agreed, apr_bzero?
>
> No, I simply removed it (as well as the one use of bzero() in
> Apache*). I don't see evidence that APR needs to provide such a
> beast.
Better and cleaner!
>
> *there is a use in the test directory but that program has not been
> APR-ized anyway
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
Re: APACHE20 problem with string.h and strings.h
Posted by Jeff Trawick <tr...@bellsouth.net>.
jean-frederic clere <jf...@fujitsu.siemens.es> writes:
> Jeff Trawick wrote:
> >
> > I think I prefer dispensing with APR's definition of bzero()
> > altogether. Why should APR be defining such a thing? (If it needed
> > to provide such a thing, it should be called apr_something(). I'll
> > suggest on the APR list removing the bzero mapping altogether.
>
> Agreed, apr_bzero?
No, I simply removed it (as well as the one use of bzero() in
Apache*). I don't see evidence that APR needs to provide such a
beast.
*there is a use in the test directory but that program has not been
APR-ized anyway
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APACHE20 problem with string.h and strings.h
Posted by jean-frederic clere <jf...@fujitsu.siemens.es>.
Jeff Trawick wrote:
>
> jean-frederic clere <jf...@fujitsu.siemens.es> writes:
>
> > It will not (and does not) help, the problem I have is that bzero() is
> > not in the default libraries so APR cannot find it, but bzero() is
> > defined in strings.h.
>
> There is an autoconf way to check non-default libraries. That is one
> possibility.
>
> > Only removing strings.h or having the #define bzero after the includes
> > will help...
>
> If APR properly detected whether or not the system had bzero(), we'd
> be okay, right?
Yes - In my case cc -c will work (bzero is defined in strings.h) but cc
-o will failed because bzero is not in the default libraries.
>
> > The problem is basicly that APR redefines the system include. That is
> > because the system include are after the apr*.h includes. We should not
> > redefine bzero or any "system" function before the system include
> > otherwise we will have problems...
> >
> > I would suggest to create a new apr_system_redef.h that would contain
> > #define bzero (it just has to be included in
> > server/mpm/prefork/prefork.c and test/test_limits.c) and any similar
> > defines.
>
> I think I prefer dispensing with APR's definition of bzero()
> altogether. Why should APR be defining such a thing? (If it needed
> to provide such a thing, it should be called apr_something(). I'll
> suggest on the APR list removing the bzero mapping altogether.
Agreed, apr_bzero?
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
Re: APACHE20 problem with string.h and strings.h
Posted by Jeff Trawick <tr...@bellsouth.net>.
jean-frederic clere <jf...@fujitsu.siemens.es> writes:
> It will not (and does not) help, the problem I have is that bzero() is
> not in the default libraries so APR cannot find it, but bzero() is
> defined in strings.h.
There is an autoconf way to check non-default libraries. That is one
possibility.
> Only removing strings.h or having the #define bzero after the includes
> will help...
If APR properly detected whether or not the system had bzero(), we'd
be okay, right?
> The problem is basicly that APR redefines the system include. That is
> because the system include are after the apr*.h includes. We should not
> redefine bzero or any "system" function before the system include
> otherwise we will have problems...
>
> I would suggest to create a new apr_system_redef.h that would contain
> #define bzero (it just has to be included in
> server/mpm/prefork/prefork.c and test/test_limits.c) and any similar
> defines.
I think I prefer dispensing with APR's definition of bzero()
altogether. Why should APR be defining such a thing? (If it needed
to provide such a thing, it should be called apr_something(). I'll
suggest on the APR list removing the bzero mapping altogether.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APACHE20 problem with string.h and strings.h
Posted by jean-frederic clere <jf...@fujitsu.siemens.es>.
Jeff Trawick wrote:
>
> jean-frederic clere <jf...@fujitsu.siemens.es> writes:
>
> > Yes, the problem is in apr_general.h where there is "unsupported"
> > prototyping...
> > +++
> > #if
> > (!APR_HAVE_BZERO)
> > #define bzero(a,b)
> > memset(a,0,b)
> > #endif
> > +++
> > I would to prevent it when there is a strings.h that contains bzero.
It will not (and does not) help, the problem I have is that bzero() is
not in the default libraries so APR cannot find it, but bzero() is
defined in strings.h.
So the #define bzero(a,b) memset(a,0,b) causes the error:
+++
/bin/sh /home3/apache20/apache/httpd-2.0/srclib/apr/libtool
--mode=compile --silent /usr/bin/cc -DSVR4 -I../../include
-I../../include/arch/unix -I../../include/arch/unix -c dir.c && touch
dir.lo
/usr/include/strings.h 55: [error]: CFE1079 expected a type
specifier
void bzero(void *,
size_t);
^
/usr/include/strings.h 55: [error]: CFE1147 declaration is
incompatible with "void *memset(void *, int, size_t)" (declared at line
62 of
"/usr/include/string.h")
void bzero(void *,
size_t);
^
+++
Only removing strings.h or having the #define bzero after the includes
will help...
The problem is basicly that APR redefines the system include. That is
because the system include are after the apr*.h includes. We should not
redefine bzero or any "system" function before the system include
otherwise we will have problems...
I would suggest to create a new apr_system_redef.h that would contain
#define bzero (it just has to be included in
server/mpm/prefork/prefork.c and test/test_limits.c) and any similar
defines.
Jean-frederic
> In srclib/apr/configure.in, we have
>
> AC_CHECK_FUNCS(bzero, [ have_bzero="1" ], [ have_bzero="0"] )
>
> I have found other cases where AC_CHECK_FUNCS() doesn't work for some
> function on some platform because that platform requires a header
> file. Maybe this will help? It works for me on Linux/glibc.
>
> Test this code on your platform and see if it results in happiness.
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvspublic/apr/configure.in,v
> retrieving revision 1.220
> diff -u -r1.220 configure.in
> --- configure.in 2001/01/28 12:18:38 1.220
> +++ configure.in 2001/01/30 11:57:38
> @@ -251,7 +251,7 @@
> fi
> AC_CHECK_FUNCS(hstrerror)
> AC_CHECK_FUNCS(memmove, [ have_memmove="1" ], [have_memmove="0" ])
> -AC_CHECK_FUNCS(bzero, [ have_bzero="1" ], [ have_bzero="0"] )
> +APR_CHECK_BZERO
>
> AC_SUBST(fork)
> AC_SUBST(have_inet_addr)
> Index: helpers/apr-conf.m4
> ===================================================================
> RCS file: /home/cvspublic/apr/helpers/apr-conf.m4,v
> retrieving revision 1.3
> diff -u -r1.3 apr-conf.m4
> --- helpers/apr-conf.m4 2001/01/09 11:05:49 1.3
> +++ helpers/apr-conf.m4 2001/01/30 11:57:52
> @@ -534,3 +534,31 @@
> AC_MSG_RESULT([$ac_cv_h_errno_cflags])
> fi
> ])
> +
> +dnl
> +dnl check for bzero
> +dnl Some platforms need strings.h to be included in order to detect
> +dnl bzero, so we can't use AC_CHECK_FUNCS
> +dnl
> +AC_DEFUN(APR_CHECK_BZERO,[
> +AC_CACHE_CHECK(for bzero, ac_cv_func_bzero,[
> +AC_TRY_COMPILE([
> +#ifdef HAVE_STRINGS_H
> +#include <strings.h>
> +#endif
> +#include <string.h>
> +],[
> +bzero(0,0);
> +],[
> + ac_cv_func_bzero=yes
> +],[
> + ac_cv_func_bzero=no
> +])
> +])
> +
> +if test "$ac_cv_func_bzero" = "yes"; then
> + have_bzero="1"
> +else
> + have_bzero="0"
> +fi
> +])
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
Re: APACHE20 problem with string.h and strings.h
Posted by Jeff Trawick <tr...@bellsouth.net>.
jean-frederic clere <jf...@fujitsu.siemens.es> writes:
> Yes, the problem is in apr_general.h where there is "unsupported"
> prototyping...
> +++
> #if
> (!APR_HAVE_BZERO)
> #define bzero(a,b)
> memset(a,0,b)
> #endif
> +++
> I would to prevent it when there is a strings.h that contains bzero.
In srclib/apr/configure.in, we have
AC_CHECK_FUNCS(bzero, [ have_bzero="1" ], [ have_bzero="0"] )
I have found other cases where AC_CHECK_FUNCS() doesn't work for some
function on some platform because that platform requires a header
file. Maybe this will help? It works for me on Linux/glibc.
Test this code on your platform and see if it results in happiness.
Index: configure.in
===================================================================
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.220
diff -u -r1.220 configure.in
--- configure.in 2001/01/28 12:18:38 1.220
+++ configure.in 2001/01/30 11:57:38
@@ -251,7 +251,7 @@
fi
AC_CHECK_FUNCS(hstrerror)
AC_CHECK_FUNCS(memmove, [ have_memmove="1" ], [have_memmove="0" ])
-AC_CHECK_FUNCS(bzero, [ have_bzero="1" ], [ have_bzero="0"] )
+APR_CHECK_BZERO
AC_SUBST(fork)
AC_SUBST(have_inet_addr)
Index: helpers/apr-conf.m4
===================================================================
RCS file: /home/cvspublic/apr/helpers/apr-conf.m4,v
retrieving revision 1.3
diff -u -r1.3 apr-conf.m4
--- helpers/apr-conf.m4 2001/01/09 11:05:49 1.3
+++ helpers/apr-conf.m4 2001/01/30 11:57:52
@@ -534,3 +534,31 @@
AC_MSG_RESULT([$ac_cv_h_errno_cflags])
fi
])
+
+dnl
+dnl check for bzero
+dnl Some platforms need strings.h to be included in order to detect
+dnl bzero, so we can't use AC_CHECK_FUNCS
+dnl
+AC_DEFUN(APR_CHECK_BZERO,[
+AC_CACHE_CHECK(for bzero, ac_cv_func_bzero,[
+AC_TRY_COMPILE([
+#ifdef HAVE_STRINGS_H
+#include <strings.h>
+#endif
+#include <string.h>
+],[
+bzero(0,0);
+],[
+ ac_cv_func_bzero=yes
+],[
+ ac_cv_func_bzero=no
+])
+])
+
+if test "$ac_cv_func_bzero" = "yes"; then
+ have_bzero="1"
+else
+ have_bzero="0"
+fi
+])
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: APACHE20 problem with string.h and strings.h
Posted by jean-frederic clere <jf...@fujitsu.siemens.es>.
Martin Kraemer wrote:
>
> On Mon, Jan 29, 2001 at 06:50:01PM +0100, jean-frederic clere wrote:
> > Hi Martin,
> >
> > I have tried APACHE20 on the SVR4 MACHINE and the compilation fails:
> > It appears that APR detects that bzero, bcopy and bcmp are not supported
> > (ucb), and tries to replace them. But it also includes strings.h that
> > contains their definition.
>
> > For example:
> > httpd-2.0/srclib/apr/tables/apr_tables.c
> > +++
> > #ifdef
> > HAVE_STRING_H
> > #include <string.h>
> > #endif
> > #if
> > APR_HAVE_STRINGS_H
> > #include <strings.h>
> > #endif
> > +++
> >
> > The problem occurs like that:
> > bzero is defined as memset(void *,0, size_t) in
> > httpd-2.0/srclib/apr/include/apr_general.h
> > Of course when strings.h is included the compilation fails...
> >
> > What is the solution:
> > - use /usr/ucb/cc? - I do not like it -
> > - Add -lucb to the libraries? - I am afraid APR should be the tool to
> > avoid this kind of libraries.
> > - Try to fix the problem in APACHE, why do we include strings.h if we
> > try to emulate the routines that are inside?
> >
> > Any comments? Before I try to explain the 3d solution to new-httpd
>
> I don't see the necessity for such a strict logical separation between
> string.h and strings.h as it is traditionally existing in SVR4.
> In SVR4, strings.h in "the berkeley (ucb) functions" and string.h
> is "the at&t (sysv) functions".
>
> But that need not be the case for other OS's. Look at FreeBSD: though
> it is BSD-derived, all it has in <strings.h> is:
> /* ...
> * @(#)strings.h 8.1 (Berkeley) 6/2/93
> */
> #include <string.h>
>
> But in <strings.h>, it protects the non-ASNI functions like this:
> /* Nonstandard routines */
> #if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE)
> int bcmp __P((const void *, const void *, size_t));
> void bcopy __P((const void *, void *, size_t));
> void bzero __P((void *, size_t));
> ...
>
> I think it is "the fault of" SVR4 that they integrated both environments
> so poorly, and did not provide a way to exclude the non-ANSI definitions.
>
> But back to your list:
> > What is the solution:
> > - use /usr/ucb/cc? - I do not like it -
>
> Sometimes, this is the easiest way. It used to be a PITA back in the
> beginning of SVR4 (SINIX-5.4x), but works quite well today with CDS++.
> I ported httperf recently in a few minutes (and I remember it took me
> hours a few years ago), and httperf is a very tricky application which
> relies heavily on BSD'isms. OTOH, this is not BSD, it's SVR4, and I'd
> prefer not to have to rely on the /usr/ucb/cc "emulation".
>
> > - Add -lucb to the libraries? - I am afraid APR should be the tool to
> > avoid this kind of libraries.
>
> Right. But still, considering a "-lc -lucb" was the best SVR4 workaround
> for years. It links against libc first, and only if something (rindex etc)
> is still undefined, it resolves it from libucb. By using this order, you
> avoid the traditional core dumps you get when mixing readdir() from libc
> with the readdir() from libucb. But when apr supplies replacements anyway,
> we should not have a need for libucb at all.
>
> > - Try to fix the problem in APACHE, why do we include strings.h if we
> > try to emulate the routines that are inside?
>
> Now what causes the problem? IMO it's THE ORDER of includes. If apr were
> to include the system headers <string*.h> FIRST, and THEN provide their
> override, then nothing whatsoever would go wrong (even if they use different
> const qualifiers than the system includes...).
>
> And that's IMHO the way to go.
Yes, the problem is in apr_general.h where there is "unsupported"
prototyping...
+++
#if
(!APR_HAVE_BZERO)
#define bzero(a,b)
memset(a,0,b)
#endif
+++
I would to prevent it when there is a strings.h that contains bzero.
Jean-frederic
>
> Martin
> --
> <Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
> Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany