From jss@ast.cam.ac.uk

Test 7 fails on our alpha machine using OSF4.0d and the native CC
compiler​:

xalph3​:~/perl5.005_03/t> ./perl /tmp/fs.t
1..28
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
not ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
...

How safe is this to install?

The only warnings I can find in the compilation are ones arouble long
doubles​:

cc -c -std -fprm d -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C
-O3 -DVERSION=\"1.02\" -DXS_VERSION=\"1.02\" -I../.. POSIX.c
cc​: Warning​: POSIX.xs, line 352​: Type long double has the same
representation as type double on this platform.
long double
^
cc​: Warning​: POSIX.xs, line 1315​: In this statement, a floating point
error occurs in evaluating the expression "1.8e308".
  return HUGE_VAL;

myconfig output​:
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=dec_osf, osvers=4.0, archname=alpha-dec_osf
  uname='osf1 xalph3.ast.cam.ac.uk v4.0 564 alpha '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='cc', optimize='-O3', gccversion=
  cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C'
  ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include
-DLANGUAGE_C'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=8, ptrsize=8, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='ld', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc
/usr/lib /var/shlib
  libs=-ldbm -ldb -lm
  libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-Wl,-rpath,/usr/local/lib/perl5/5.00503/alpha-dec_osf/CORE'
  cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -s
-L/usr/local/lib'

Thanks,

Jeremy.

--
Jeremy Sanders jss@​ast.cam.ac.uk Pembroke College, Cambridge. CB2 1RF
(01223) 337511 Institute of Astronomy, Madingley Road, Cambridge. CB3 0HA

From [Unknown Contact. See original ticket]

On Mon, 23 Aug 1999 at 14​:16​:01 +0100, Jeremy Sanders wrote​:

Hi,

Test 7 [of t/io/fs.t - IGP] fails on our alpha machine using OSF4.0d
and the native CC compiler​:

How safe is this to install?

If everything else works, pretty safe. But it would be a good idea to
get to the bottom of it to make sure. If you look at fs.t, you'll see
that it's doing a chmod on 'a' and expecting the mode of 'c' to change -
since they're linked. Run the test up to that point and check the mode
and linkage of the files. Hack fs.t to print out the value of $mode, to
see what it thinks it is.

A thought - is the file system you're doing this in local or NFS? If the
latter, we could be seeing some mode-caching bug kicking in, in which
case it's probably going to be time-dependent :-(

The only warnings I can find in the compilation are ones arouble long
-O3 -DVERSION=\"1.02\" -DXS_VERSION=\"1.02\" -I../.. POSIX.c
cc​: Warning​: POSIX.xs, line 352​: Type long double has the same
representation as type double on this platform.

Doesn't sound too bad to me.

cc​: Warning​: POSIX.xs, line 1315​: In this statement, a floating point
error occurs in evaluating the expression "1.8e308".
return HUGE_VAL;

Doesn't look too important to me, and highly unlikely to be related.

Jeremy Sanders jss@​ast.cam.ac.uk Pembroke College, Cambridge. CB2 1RF
(01223) 337511 Institute of Astronomy, Madingley Road, Cambridge. CB3 0HA

I'm about two miles away, BTW.

Ian

From [Unknown Contact. See original ticket]

On Mon, 23 Aug 1999, Ian Phillipps wrote​:

On Mon, 23 Aug 1999 at 14​:16​:01 +0100, Jeremy Sanders wrote​:

Hi,

Test 7 [of t/io/fs.t - IGP] fails on our alpha machine using OSF4.0d
and the native CC compiler​:

How safe is this to install?

If everything else works, pretty safe. But it would be a good idea to
get to the bottom of it to make sure. If you look at fs.t, you'll see
that it's doing a chmod on 'a' and expecting the mode of 'c' to change -
since they're linked. Run the test up to that point and check the mode
and linkage of the files. Hack fs.t to print out the value of $mode, to
see what it thinks it is.

Before test 7​:

xpc6​:~/<1>t/tmp> ls -l
total 0
-rwxrwxrwx 3 jss users 0 Aug 24 10​:18 a
-rwxrwxrwx 3 jss users 0 Aug 24 10​:18 b
-rwxrwxrwx 3 jss users 0 Aug 24 10​:18 c
-rw-rw-rw- 1 jss users 0 Aug 24 10​:18 x

$mode = 33279 (100777 octal) after test 7

ls reveals same information afterwards.

A thought - is the file system you're doing this in local or NFS? If the
latter, we could be seeing some mode-caching bug kicking in, in which
case it's probably going to be time-dependent :-(

I'm compiling Perl on Digital Unix onto my user directory which is mounted
by nfs from a Linux 2.2.11 RedHat machine (using knfsd as the nfs server).

I introduced a key pause between tests 6 and 7. If I hit return
immediately, then test 7 fails. If I wait about 5 seconds, then it works!
It must be some strange nfs fault.

The program was paused to get the above debugging details.

I copied the complete build directory to a local disk on the alpha. Test 7
worked fine.

Thanks!

Jeremy.

--
Jeremy Sanders jss@​ast.cam.ac.uk Pembroke College, Cambridge. CB2 1RF
(01223) 337511 Institute of Astronomy, Madingley Road, Cambridge. CB3 0HA

From [Unknown Contact. See original ticket]

On Tue, 24 Aug 1999 at 10​:31​:20 +0100, Jeremy Sanders wrote​:

On Mon, 23 Aug 1999, Ian Phillipps wrote​:

Test 7 [of t/io/fs.t - IGP] fails on our alpha machine using OSF4.0d
and the native CC compiler​:

I'm compiling Perl on Digital Unix onto my user directory which is mounted
by nfs from a Linux 2.2.11 RedHat machine (using knfsd as the nfs server).

I introduced a key pause between tests 6 and 7. If I hit return
immediately, then test 7 fails. If I wait about 5 seconds, then it works!
It must be some strange nfs fault.

I copied the complete build directory to a local disk on the alpha. Test 7
worked fine.

So, nfs attribute caching it is.

This must be a peculiarity of the Digital Unix nfs client, or we should
have had a lot more of these.

Out of curiosity - does your nfs-client version report the same inode
number in each case? It really ought to.

Ian

From @jhi

Jeremy Sanders writes​:

Hi,

Test 7 fails on our alpha machine using OSF4.0d and the native CC
compiler​:

xalph3​:~/perl5.005_03/t> ./perl /tmp/fs.t
1..28
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
not ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
...

How safe is this to install?

Pretty safe if that is the only failing subtest in the whole test suite.

It would be nice to know what's wrong with it, though. The subtests
#6 and #7 deals with chmod/stat and #7 failing means that stat
returned something unexpected.

If you could add the following line after the "not ok 7" in t/io/fs.t​:

printf "# mode = %o\n", $mode;

and rerun the test?

The only warnings I can find in the compilation are ones arouble long
doubles​:

cc -c -std -fprm d -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C
-O3 -DVERSION=\"1.02\" -DXS_VERSION=\"1.02\" -I../.. POSIX.c
cc​: Warning​: POSIX.xs, line 352​: Type long double has the same
representation as type double on this platform.
long double
^

This is just a harmless warning.

cc​: Warning​: POSIX.xs, line 1315​: In this statement, a floating point
error occurs in evaluating the expression "1.8e308".
return HUGE_VAL;

This is also pretty harmless. In fact, AFAIK, it is a compiler bug
(no, there won't be a floating point error) and it will be fixed in
future releases of Tru64 UNIX.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen