You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/12/14 11:33:36 UTC
[PATCH] Add --with-efence option.
I was using Electric Fence when I was debugging the pool code.
It helped a bit, so it might be good to have it as a configure
option (--with-efence[=DIR]).
However, I'm wondering if we could have a GPL v. BSD disrepency
here since efence is under GPL and we're still BSD. So, I won't
commit unless someone says it is okay.
Note that this requires the addition of the
apr_platform_runtime_link_flag variable so that we can properly
do the LDFLAGS on certain OSes (Solaris). Linux has -rpath, but
I'm not 100% sure we need it. Also, the latest GNU binutils says
that its ld accepts -R as well - can anyone confirm this on
older Linux boxen? (It seems that setting it to -Wl,-rpath screws
up the APR_ADDTO macro.) -- justin
Index: CHANGES
===================================================================
RCS file: /home/cvs/apr/CHANGES,v
retrieving revision 1.197
diff -u -r1.197 CHANGES
--- CHANGES 2001/12/14 10:06:19 1.197
+++ CHANGES 2001/12/14 10:24:16
@@ -1,5 +1,8 @@
Changes with APR b1
+ *) Add --with-efence to allow usage of Electric Fence.
+ [Justin Erenkrantz]
+
*) Put new pools code in place which allows applications to
switch off locking on pools operations in case a pool is
guaranteed to never being used in more than one thread
Index: configure.in
===================================================================
RCS file: /home/cvs/apr/configure.in,v
retrieving revision 1.390
diff -u -r1.390 configure.in
--- configure.in 2001/12/14 02:45:15 1.390
+++ configure.in 2001/12/14 10:24:17
@@ -131,12 +131,15 @@
fi
dnl On AIX, libraries need to be specified on the link of lib_target
+lib_target_libs=""
case $host in
*aix*)
lib_target_libs="\$(EXTRA_LIBS)";
;;
+ *-solaris2*)
+ apr_platform_runtime_link_flag="-R"
+ ;;
*)
- lib_target_libs=""
;;
esac
@@ -184,6 +187,23 @@
fi
fi
)dnl
+
+dnl Electric Fence malloc checker.
+dnl --with-efence specifies the path to Electric Fence
+AC_ARG_WITH(efence,
+ [ --with-efence[[=DIR]] path to Electric Fence installation],
+ [ apr_efence_dir="$withval"
+ if test "$apr_efence_dir" != "yes"; then
+ APR_ADDTO(LDFLAGS,[-L$apr_efence_dir/lib])
+ if test "x$apr_platform_runtime_link_flag" != "x"; then
+ APR_ADDTO(LDFLAGS,
+ [$apr_platform_runtime_link_flag$apr_efence_dir/lib])
+ fi
+ fi
+ AC_CHECK_LIB(efence, malloc,
+ [ APR_ADDTO(LIBS,-lefence) ],
+ [ AC_MSG_ERROR(Electric Fence requested but not detected) ])
+ ])
if test "$host" = "i586-pc-beos"; then
AC_ARG_ENABLE(malloc-debug,[ --enable-malloc-debug Switch on malloc_debug for BeOS],
Re: [PATCH] Add --with-efence option.
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Dec 14, 2001 at 10:00:28AM -0800, Justin Erenkrantz wrote:
> > Maybe I'm missing something, but I don't see how the library runtime
> > path would have any bearing on an AC test. It either links or it fails,
> > right?
>
> Okay, say we do that. Remember that AC_TRY_RUN will compile, link,
> and run. By that time we've done the following:
>
> LDFLAGS="-Lpath/to/efence/lib -Rpath/to/efence/lib"
> LIBS="-lefence"
>
> The autoconf tests are handled by $CC *not* libtool. A linker that
> doesn't understand -R will die. We don't use libtool until the
> make process begins. Which means we need the platform-specific
> runtime linker flag at configure time. When we do make, we can
> rely on libtool handling the -R though.
>
> However, say we don't add the platform specific link flag, then all
> runs will fail on -R needing platforms since we linked against
> efence, but didn't specify where its runtime path was. -- justin
Justin and I have come up with a proposal. (Justin: I'll expect you
to correct me if I misrepresent you.)
Why don't we rename some variables:
INCLUDES --> AP_INCLUDES
LIBS --> AP_LIBS
<null> --> AP_LDFLAGS
As we do our autoconf tests, we would slowly accumulate flags in the AP_*
vars as we do now with INCLUDES and LIBS, but right now we don't have a
protected LDFLAGS that won't get picked up by the AC tests. For the
above case with efence we'd do:
(pseudo-code):
AP_INCLUDES += "-I/path/where/we/found/efence/includes"
AP_LIBS += "-lefence"
AP_LDFLAGS += "-L/path/where/we/found/efence/libs -R/path/where/we/found/efence/libs"
-aaron
Re: [PATCH] Add --with-efence option.
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Dec 14, 2001 at 09:53:02AM -0800, Aaron Bannert wrote:
> On Fri, Dec 14, 2001 at 09:44:23AM -0800, Justin Erenkrantz wrote:
> > On Fri, Dec 14, 2001 at 09:29:54AM -0800, Aaron Bannert wrote:
> > > The -R flag shouldn't need to be solaris specific. Libtool interprets -R
> > > and -rpath in the same way, and it turns it into whatever is appropriate
> > > for the local linker. So just add -rpath (or -R if you prefer) always
> > > for all platforms.
> >
> > The problem is at this point in the configure test, we don't
> > have libtool up. =) I thought about that. But, I'm afraid
> > that if we don't put the platform specific option there and we
> > do an AC_TRY_RUN with the -R flag, we'll die due to a bad
> > runtime search path. Am I wrong? -- justin
>
> Maybe I'm missing something, but I don't see how the library runtime
> path would have any bearing on an AC test. It either links or it fails,
> right?
Okay, say we do that. Remember that AC_TRY_RUN will compile, link,
and run. By that time we've done the following:
LDFLAGS="-Lpath/to/efence/lib -Rpath/to/efence/lib"
LIBS="-lefence"
The autoconf tests are handled by $CC *not* libtool. A linker that
doesn't understand -R will die. We don't use libtool until the
make process begins. Which means we need the platform-specific
runtime linker flag at configure time. When we do make, we can
rely on libtool handling the -R though.
However, say we don't add the platform specific link flag, then all
runs will fail on -R needing platforms since we linked against
efence, but didn't specify where its runtime path was. -- justin
Re: [PATCH] Add --with-efence option.
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Dec 14, 2001 at 09:44:23AM -0800, Justin Erenkrantz wrote:
> On Fri, Dec 14, 2001 at 09:29:54AM -0800, Aaron Bannert wrote:
> > The -R flag shouldn't need to be solaris specific. Libtool interprets -R
> > and -rpath in the same way, and it turns it into whatever is appropriate
> > for the local linker. So just add -rpath (or -R if you prefer) always
> > for all platforms.
>
> The problem is at this point in the configure test, we don't
> have libtool up. =) I thought about that. But, I'm afraid
> that if we don't put the platform specific option there and we
> do an AC_TRY_RUN with the -R flag, we'll die due to a bad
> runtime search path. Am I wrong? -- justin
Maybe I'm missing something, but I don't see how the library runtime
path would have any bearing on an AC test. It either links or it fails,
right?
-aaron
Re: [PATCH] Add --with-efence option.
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Dec 14, 2001 at 09:29:54AM -0800, Aaron Bannert wrote:
> The -R flag shouldn't need to be solaris specific. Libtool interprets -R
> and -rpath in the same way, and it turns it into whatever is appropriate
> for the local linker. So just add -rpath (or -R if you prefer) always
> for all platforms.
The problem is at this point in the configure test, we don't
have libtool up. =) I thought about that. But, I'm afraid
that if we don't put the platform specific option there and we
do an AC_TRY_RUN with the -R flag, we'll die due to a bad
runtime search path. Am I wrong? -- justin
Re: [PATCH] Add --with-efence option.
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Dec 14, 2001 at 02:33:36AM -0800, Justin Erenkrantz wrote:
> I was using Electric Fence when I was debugging the pool code.
> It helped a bit, so it might be good to have it as a configure
> option (--with-efence[=DIR]).
>
> However, I'm wondering if we could have a GPL v. BSD disrepency
> here since efence is under GPL and we're still BSD. So, I won't
> commit unless someone says it is okay.
>
> Note that this requires the addition of the
> apr_platform_runtime_link_flag variable so that we can properly
> do the LDFLAGS on certain OSes (Solaris). Linux has -rpath, but
> I'm not 100% sure we need it. Also, the latest GNU binutils says
> that its ld accepts -R as well - can anyone confirm this on
> older Linux boxen? (It seems that setting it to -Wl,-rpath screws
> up the APR_ADDTO macro.) -- justin
...
> @@ -131,12 +131,15 @@
> fi
>
> dnl On AIX, libraries need to be specified on the link of lib_target
> +lib_target_libs=""
> case $host in
> *aix*)
> lib_target_libs="\$(EXTRA_LIBS)";
> ;;
> + *-solaris2*)
> + apr_platform_runtime_link_flag="-R"
> + ;;
> *)
> - lib_target_libs=""
> ;;
> esac
>
> @@ -184,6 +187,23 @@
The -R flag shouldn't need to be solaris specific. Libtool interprets -R
and -rpath in the same way, and it turns it into whatever is appropriate
for the local linker. So just add -rpath (or -R if you prefer) always
for all platforms.
-aaron
Re: [PATCH] Add --with-efence option.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 14, 2001 at 02:33:36AM -0800, Justin Erenkrantz wrote:
> I was using Electric Fence when I was debugging the pool code.
> It helped a bit, so it might be good to have it as a configure
> option (--with-efence[=DIR]).
>
> However, I'm wondering if we could have a GPL v. BSD disrepency
> here since efence is under GPL and we're still BSD. So, I won't
> commit unless someone says it is okay.
If we *required* the efence library, then we would have to release under the
GPL. But if the *user* elects to use this option, then we're okay.
This patch is totally fine to integrate, and would be a good thing for the
new pool code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] Add --with-efence option.
Posted by Ian Holsman <ia...@apache.org>.
Sander Striker wrote:
>>From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
>>Sent: 14 December 2001 11:34
>>
>
>>I was using Electric Fence when I was debugging the pool code.
>>It helped a bit, so it might be good to have it as a configure
>>option (--with-efence[=DIR]).
>>
>
> +1 :)
+1
I'll want to add a purify option later on as well. (thats commercial)
>
>
>>However, I'm wondering if we could have a GPL v. BSD disrepency
>>here since efence is under GPL and we're still BSD. So, I won't
>>commit unless someone says it is okay.
>>
>
> AFAI understand, we are not distributing efence so we are clear.
> We are also not shipping binaries with efence linked in, so that's
> no issue either. But IANAL, someone else might have a better clue
> than me.
>
> Sander
>
>
>>Note that this requires the addition of the
>>apr_platform_runtime_link_flag variable so that we can properly
>>do the LDFLAGS on certain OSes (Solaris). Linux has -rpath, but
>>I'm not 100% sure we need it. Also, the latest GNU binutils says
>>that its ld accepts -R as well - can anyone confirm this on
>>older Linux boxen? (It seems that setting it to -Wl,-rpath screws
>>up the APR_ADDTO macro.) -- justin
>>
>>Index: CHANGES
>>===================================================================
>>RCS file: /home/cvs/apr/CHANGES,v
>>retrieving revision 1.197
>>diff -u -r1.197 CHANGES
>>--- CHANGES 2001/12/14 10:06:19 1.197
>>+++ CHANGES 2001/12/14 10:24:16
>>@@ -1,5 +1,8 @@
>> Changes with APR b1
>>
>>+ *) Add --with-efence to allow usage of Electric Fence.
>>+ [Justin Erenkrantz]
>>+
>> *) Put new pools code in place which allows applications to
>> switch off locking on pools operations in case a pool is
>> guaranteed to never being used in more than one thread
>>Index: configure.in
>>===================================================================
>>RCS file: /home/cvs/apr/configure.in,v
>>retrieving revision 1.390
>>diff -u -r1.390 configure.in
>>--- configure.in 2001/12/14 02:45:15 1.390
>>+++ configure.in 2001/12/14 10:24:17
>>@@ -131,12 +131,15 @@
>> fi
>>
>> dnl On AIX, libraries need to be specified on the link of lib_target
>>+lib_target_libs=""
>> case $host in
>> *aix*)
>> lib_target_libs="\$(EXTRA_LIBS)";
>> ;;
>>+ *-solaris2*)
>>+ apr_platform_runtime_link_flag="-R"
>>+ ;;
>> *)
>>- lib_target_libs=""
>> ;;
>> esac
>>
>>@@ -184,6 +187,23 @@
>> fi
>> fi
>> )dnl
>>+
>>+dnl Electric Fence malloc checker.
>>+dnl --with-efence specifies the path to Electric Fence
>>+AC_ARG_WITH(efence,
>>+ [ --with-efence[[=DIR]] path to Electric Fence installation],
>>+ [ apr_efence_dir="$withval"
>>+ if test "$apr_efence_dir" != "yes"; then
>>+ APR_ADDTO(LDFLAGS,[-L$apr_efence_dir/lib])
>>+ if test "x$apr_platform_runtime_link_flag" != "x"; then
>>+ APR_ADDTO(LDFLAGS,
>>+ [$apr_platform_runtime_link_flag$apr_efence_dir/lib])
>>+ fi
>>+ fi
>>+ AC_CHECK_LIB(efence, malloc,
>>+ [ APR_ADDTO(LIBS,-lefence) ],
>>+ [ AC_MSG_ERROR(Electric Fence requested but not detected) ])
>>+ ])
>>
>> if test "$host" = "i586-pc-beos"; then
>> AC_ARG_ENABLE(malloc-debug,[ --enable-malloc-debug Switch on malloc_debug for BeOS],
>>
>>
>>
>
RE: [PATCH] Add --with-efence option.
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: 14 December 2001 11:34
> I was using Electric Fence when I was debugging the pool code.
> It helped a bit, so it might be good to have it as a configure
> option (--with-efence[=DIR]).
+1 :)
> However, I'm wondering if we could have a GPL v. BSD disrepency
> here since efence is under GPL and we're still BSD. So, I won't
> commit unless someone says it is okay.
AFAI understand, we are not distributing efence so we are clear.
We are also not shipping binaries with efence linked in, so that's
no issue either. But IANAL, someone else might have a better clue
than me.
Sander
> Note that this requires the addition of the
> apr_platform_runtime_link_flag variable so that we can properly
> do the LDFLAGS on certain OSes (Solaris). Linux has -rpath, but
> I'm not 100% sure we need it. Also, the latest GNU binutils says
> that its ld accepts -R as well - can anyone confirm this on
> older Linux boxen? (It seems that setting it to -Wl,-rpath screws
> up the APR_ADDTO macro.) -- justin
>
> Index: CHANGES
> ===================================================================
> RCS file: /home/cvs/apr/CHANGES,v
> retrieving revision 1.197
> diff -u -r1.197 CHANGES
> --- CHANGES 2001/12/14 10:06:19 1.197
> +++ CHANGES 2001/12/14 10:24:16
> @@ -1,5 +1,8 @@
> Changes with APR b1
>
> + *) Add --with-efence to allow usage of Electric Fence.
> + [Justin Erenkrantz]
> +
> *) Put new pools code in place which allows applications to
> switch off locking on pools operations in case a pool is
> guaranteed to never being used in more than one thread
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr/configure.in,v
> retrieving revision 1.390
> diff -u -r1.390 configure.in
> --- configure.in 2001/12/14 02:45:15 1.390
> +++ configure.in 2001/12/14 10:24:17
> @@ -131,12 +131,15 @@
> fi
>
> dnl On AIX, libraries need to be specified on the link of lib_target
> +lib_target_libs=""
> case $host in
> *aix*)
> lib_target_libs="\$(EXTRA_LIBS)";
> ;;
> + *-solaris2*)
> + apr_platform_runtime_link_flag="-R"
> + ;;
> *)
> - lib_target_libs=""
> ;;
> esac
>
> @@ -184,6 +187,23 @@
> fi
> fi
> )dnl
> +
> +dnl Electric Fence malloc checker.
> +dnl --with-efence specifies the path to Electric Fence
> +AC_ARG_WITH(efence,
> + [ --with-efence[[=DIR]] path to Electric Fence installation],
> + [ apr_efence_dir="$withval"
> + if test "$apr_efence_dir" != "yes"; then
> + APR_ADDTO(LDFLAGS,[-L$apr_efence_dir/lib])
> + if test "x$apr_platform_runtime_link_flag" != "x"; then
> + APR_ADDTO(LDFLAGS,
> + [$apr_platform_runtime_link_flag$apr_efence_dir/lib])
> + fi
> + fi
> + AC_CHECK_LIB(efence, malloc,
> + [ APR_ADDTO(LIBS,-lefence) ],
> + [ AC_MSG_ERROR(Electric Fence requested but not detected) ])
> + ])
>
> if test "$host" = "i586-pc-beos"; then
> AC_ARG_ENABLE(malloc-debug,[ --enable-malloc-debug Switch on malloc_debug for BeOS],
>
>