On 1 October 2012 17:19, Ben Pfaff
> On Mon, Oct 01, 2012 at 09:11:31PM +0000, Ed Maste wrote:
>> Signed-off-by: Ed Maste
> Applied, thanks.
>> There should probably be an OS check to set only the appropriate
>> variables. I'm not sure if there's a generic autotest way to do that
>> building atlocal from atlocal.in though (vs. a switch on $(uname) in the
>> generated file). Perhaps not worth addressing, since they're just env
> The latter was my own thought.
Ahh, as it turns out the new jemalloc in FreeBSD 10 uses a different
config string format, so I'll eventually need a uname switch anyway
(although the FreeBSD 10 release is a ways off).
Does something like this seem reasonable?
diff --git a/tests/atlocal.in b/tests/atlocal.in
index c23f8e9..5604bf0 100644
@@ -33,12 +33,23 @@ if test $HAVE_PYTHON = yes; then
-# Enable glibc malloc debugging features.
-# Enable FreeBSD libc malloc debugging features.
+case $(uname) in
+ # Enable glibc malloc debugging features.
+ export MALLOC_CHECK_
+ export MALLOC_PERTURB_
+ # Enable FreeBSD libc malloc debugging features.
+ case $(uname -r) in
+ export MALLOC_CONF
> Do you guys use ovs-ctl (or plan to?). I'd happily take a patch to
> ovs-lib to add freebsd support there. I guess we'd either rename the
> "glibc" wrapper to something more generic or add a "bsd" or "freebsd"
> wrapper; I'd be OK with either choice.
We're not currently using ovs-ctl. Probably the closet right now is
start scripts in the FreeBSD ports tree for the db and vswitchd:
On a quick look there are some interesting bits in ovs-ctl and ovs-lib
- I'll try to investigate in more detail.