GNV and Google Test

[T.L.Hughes]

Problems with Google Test Configure script under GNV

OpenVMS V7.3-2. GNV newly installed (latest). I attempted to use GNV
to build the newly available Google Test suite.

The configure script continually hung. I don't know whether the failures are
all related. Here are a couple of the early ones.

for ac_var in `(set) 2>&1 |
sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do

This is not the first sed call in the script (the previous ones did not hang).

Next block of code with a hang in it was an attempt to find the maximum
length of command line arguments (see below).

Any ideas how to get this working?

# find the maximum length of command line arguments
echo "$as_me:$LINENO: checking the maximum length of command line arguments" >&5
echo $ECHO_N "checking the maximum length of command line arguments... $ECHO_C" >&6
if test "${lt_cv_sys_max_cmd_len+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
i=0
teststring="ABCD"

case $build_os in
msdosdjgpp*)
# On DJGPP, this test can blow up pretty badly due to problems in libc
# (any single argument exceeding 2000 bytes causes a buffer overrun
# during glob expansion). Even if it were fixed, the result of this
# check would be larger than it should be.
lt_cv_sys_max_cmd_len=12288; # 12K is about right
;;

gnu*)
# Under GNU Hurd, this test is not required because there is
# no limit to the length of command line arguments.
# Libtool will interpret -1 as no limit whatsoever
lt_cv_sys_max_cmd_len=-1;
;;

cygwin* | mingw*)
# On Win9x/ME, this test blows up -- it succeeds, but takes
# about 5 minutes as the teststring grows exponentially.
# Worse, since 9x/ME are not pre-emptively multitasking,
# you end up with a "frozen" computer, even though with patience
# the test eventually succeeds (with a max line length of 256k).
# Instead, let's just punt: use the minimum linelength reported by
# all of the supported platforms: 8192 (on NT/2K/XP).
lt_cv_sys_max_cmd_len=8192;
;;

amigaos*)
# On AmigaOS with pdksh, this test takes hours, literally.
# So we just punt and use a minimum line length of 8192.
lt_cv_sys_max_cmd_len=8192;
;;

netbsd* | freebsd* | openbsd* | darwin* | dragonfly*)
# This has been around since 386BSD, at least. Likely further.
if test -x /sbin/sysctl; then
lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
elif test -x /usr/sbin/sysctl; then
lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
else
lt_cv_sys_max_cmd_len=65536 # usable default for all BSDs
fi
# And add a safety zone
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
;;

interix*)
# We know the value 262144 and hardcode it with a safety zone (like BSD)
lt_cv_sys_max_cmd_len=196608
;;

osf*)
# Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
# due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
# nice to cause kernel panics so lets avoid the loop below.
# First set a reasonable default.
lt_cv_sys_max_cmd_len=16384
#
if test -x /sbin/sysconfig; then
case `/sbin/sysconfig -q proc exec_disable_arg_limit` in
*1*) lt_cv_sys_max_cmd_len=-1 ;;
esac
fi
;;
sco3.2v5*)
lt_cv_sys_max_cmd_len=102400
;;
sysv5* | sco5v6* | sysv4.2uw2*)
kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
if test -n "$kargmax"; then
lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[ ]//'`
else
lt_cv_sys_max_cmd_len=32768
fi
;;
*)
# If test is not a shell built-in, we'll probably end up computing a
# maximum length that is only half of the actual maximum length, but
# we can't tell.
SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
while (test "X"`$SHELL $0 --fallback-echo "X$teststring" 2>/dev/null` \
= "XX$teststring") >/dev/null 2>&1 &&
new_result=`expr "X$teststring" : ".*" 2>&1` &&
lt_cv_sys_max_cmd_len=$new_result &&
test $i != 17 # 1/2 MB should be enough
do
i=`expr $i + 1`
teststring=$teststring$teststring
done
teststring=
# Add a significant safety factor because C++ compilers can tack on massive
# amounts of additional arguments before passing them to the linker.
# It appears as though 1/2 is a usable value.
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
;;
esac

fi

[Ian Miller.]

exactly which version of GNV do you have and are you aware of John Malmbergs fixes for GNV?

[T.L.Hughes]

GNV Version is :

product install gnv /source=dsa1:[hpproducts.gnv]/dest=dkc200:[gnv]

1 - DEC AXPVMS GNV V1.6-2 Layered Product
2 - DEC AXPVMS GNV A1.5-3 Layered Product

I wasn't aware of any fixes, I'll look into that. Thanks.

- Tracy

[Hoff]

There are no fixes from HP as yet. gnv is open-source, and one of the folks that once worked on gnv for HP has published various fixes for gnv that have not yet been incorporated back into the HP version.

ftp://eisner.encompasserve.org/GNV/

[Ian Miller.]

Current GNV is later than the one you have. See
http://h71000.www7.hp.com/opensource/gnv.html

Do also see John M patches also.