From schinder@pobox.com

And again, the single failure​:

lib/anydbm..........#
# anydbm.t test 12 will fail when AnyDBM_File uses the combination of
# DB_File and Berkeley DB 2.4.10 (or greater).
# You are using DB_File 1.71 and Berkeley DB 2.4.14
#
# Berkeley DB 2 from version 2.4.10 onwards does not allow null keys.
# This feature will be reenabled in a future version of Berkeley DB.
#
FAILED at test 12

Anyone else think that this test should simply be turned off under
these circumstances before 5.6 is officially released? Alternatively,
does anyone have any way of using a later BerkeleyDB (I have both 2.77
and 3.something installed) short of performing surgery on glibc?

Site configuration information for perl 5.00563:

Configured by schinder at Thu Dec  9 10:17:03 EST 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration:
  Platform:
    osname=linux, osvers=2.2.13, archname=ppc-linux
    uname='linux c22234-c.scllg1.pa.home.com 2.2.13 #2 wed oct 20 09:41:39 edt 1999 ppc unknown '
    config_args='-Dcc=gcc -Dprefix=/usr/local -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='gcc', optimize='-O2', gccversion=2.95.2 19991024 (release)
    cppflags='-Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00563:
    lib
    /usr/local/lib/perl5/5.00563/ppc-linux
    /usr/local/lib/perl5/5.00563
    /usr/local/lib/site_perl/5.00563/ppc-linux
    /usr/local/lib/site_perl
    .


Environment for perl 5.00563:
    HOME=/usr/local/src
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/usr/local/lib:/usr/local/qt/lib:/lib:/usr/lib:/usr/X11R6/lib
    LOGDIR (unset)
    PATH=/usr/local/bin:/bin:/sbin:/usr/bin:/usr/etc:/usr/sbin:/usr/local/sbin:/usr/X11R6/bin:/var/qmail/bin:.
    PERL_BADLANG (unset)
    SHELL=/bin/sh

From @doughera88

On Thu, 9 Dec 1999 schinder@​pobox.com wrote​:

# anydbm.t test 12 will fail when AnyDBM_File uses the combination of
# DB_File and Berkeley DB 2.4.10 (or greater).
# You are using DB_File 1.71 and Berkeley DB 2.4.14

Anyone else think that this test should simply be turned off under
these circumstances before 5.6 is officially released?

Good question. It *is* an imcompatible change and the test is reporting a
true failure to do what an earlier version could do. However, it's also a
bit of an odd corner case -- I don't know how prevalent and important a
problem it will be in practice.

I think the message is clear and self-explanatory, but I too wonder
whether the number of redundant reports due to this failure will outnumber
the number of bogus localtime() reports we get in 2000.

  Andy Dougherty doughera@​lafayette.edu
  Dept. of Physics
  Lafayette College, Easton PA 18042

From [Unknown Contact. See original ticket]

On 9 Dec 1999 schinder@​pobox.com wrote​:

Anyone else think that this test should simply be turned off under
these circumstances before 5.6 is officially released?

Let's see about putting out some kind of warning at Configure time,
though. "You seem to have an incompatible version..."

--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case​: http​://www.rahul.net/jeffrey/ovs/

From @pmqs

From​: Andy Dougherty [mailto​:doughera@​lafayette.edu]

On Thu, 9 Dec 1999 schinder@​pobox.com wrote​:

# anydbm.t test 12 will fail when AnyDBM_File uses the
combination of
# DB_File and Berkeley DB 2.4.10 (or greater).
# You are using DB_File 1.71 and Berkeley DB 2.4.14

Anyone else think that this test should simply be turned off under
these circumstances before 5.6 is officially released?

Good question. It *is* an imcompatible change and the test
is reporting a
true failure to do what an earlier version could do.
However, it's also a
bit of an odd corner case -- I don't know how prevalent and
important a
problem it will be in practice.

I think the message is clear and self-explanatory, but I too wonder
whether the number of redundant reports due to this failure
will outnumber
the number of bogus localtime() reports we get in 2000.

The Sleepycat folk have said that they will re-enable null keys in a future
release

Paul

From @doughera88

On Thu, 9 Dec 1999 paul.marquess@​bt.com wrote​:

The Sleepycat folk have said that they will re-enable null keys in a future
release

Oh I know, but I don't expect them to hurry up and do it quickly.
I think we're going to have this issue hanging around for a while.

  Andy Dougherty doughera@​lafayette.edu

From [Unknown Contact. See original ticket]

The Sleepycat folk have said that they will re-enable null keys in a future
release

But unfortunatly on SCO 3 & 5, their standard dbm packages don't support neither
null keys. So even when the Sleepycat folks will have re-enabled null keys, the
AnyDbm test #12 will still fail on those platforms :-(

François Désarménien