Mailing List Archive: buglets on OSF/1 (Re: 5.002 beta 1)

buglets on OSF/1 (Re: 5.002 beta 1)

Nov 21, 1995, 3:33 PM

Post #1 of 5 (493 views)

>>>Larry Wall said:
> If you're adventurous, have a look at
>
> ftp://ftp.sems.com/pub/outgoing/perl5.0/perl5.002beta1.tar.gz
>
> Many thanks to Andy for doing the integration.
[...]

On OSF/1 V3.2C (OSF1 o01 V3.2 148 alpha) I got 4 buglets:

1) ===========
# ./Configure -des -Dprefix=/home/ach/test/perl
...
# make
...
# make test
...
lib/db-recno...ok
lib/english....ok
lib/gdbm.......ok
lib/ndbm.......ok
lib/odbm.......odbm store returned -1, errno 2, key "goner1" at ./lib/odbm.t line 38.
FAILED on test 4
lib/posix......ok
lib/sdbm.......ok
lib/soundex....Failed 1 test, 98.89% okay.
ok
u=0.366667 s=0.8 cu=13.4167 cs=8.7 files=90 tests=1926

2) ===========
Obviously I'm wrong but I thought that *DB* stuff would now be found in
/usr/local/{lib,include} by default. But gdbm and db extentions are not
build (no .c,.o... files in the ext/{DB_File,GDBM_File}).
So it is not found by 'default' :-( :-(.

-r--r--r-- 1 root bin 8214 Aug 25 01:37 /usr/local/include/db.h
-rw-r--r-- 1 root staff 4655 Aug 25 02:28 /usr/local/include/gdbm.h

Using the way INSTALL suggests

# make clean
# mv config.sh config.sh.old
# ./Configure -des -Dprefix=/home/ach/test/perl \
-Dlocincpth="/usr/local/include" -Dloclibpth="/usr/local/lib"
...
<gdbm.h> NOT found.
Looking for extensions...
What extensions do you wish to load dynamically?
[Fcntl NDBM_File ODBM_File POSIX SDBM_File Socket]
What extensions do you wish to load statically? [none]
...

doesn't fix the problem. Maybe OSFs cc is special as /usr/local/lib is
in the default ld path but the cc preprocessor backend does not search /usr/local/include by default.

I changed the OSF/1 hints file (as I did with 5.001m) and that worked.

--- dec_osf.sh.save Fri Nov 10 17:49:08 1995
+++ dec_osf.sh Tue Nov 21 22:18:47 1995
@@ -7,5 +7,5 @@
esac
;;
esac
-ccflags="$ccflags -DSTANDARD_C"
+ccflags="$ccflags -DSTANDARD_C -I/usr/local/include"
lddlflags='-shared -expect_unresolved "*" -s -hidden'

3) ===========
Don't know if this is intended but '.perl installman' of make install
ignores Configures -Dprefix=/home/ach/test/perl option and tries to
install below /usr/local/man (wasn't /usr/local/perl5/man/man3 the default???)

chmod 755 /home/ach/test/perl/bin/pod2latex
Installing /usr/local/man/man1/a2p.1
Can't install /usr/local/man/man1/a2p.1: Permission denied
Installing /usr/local/man/man1/s2p.1
Can't install /usr/local/man/man1/s2p.1: Permission denied

Warning: perl appears in your path in the following locations beyond where
we just installed it:
/usr/local/bin/perl

./perl installman
../perl -I ../lib ../pod/pod2man perl.pod > /usr/local/man/man1/perl.1
sh: /usr/local/man/man1/perl.1: cannot create
Command failed!!!
../perl -I ../lib ../pod/pod2man perlbook.pod > /usr/local/man/man1/perlbook.1
sh: /usr/local/man/man1/perlbook.1: cannot create
Command failed!!!
...

running installman alone and specifying man{1,3}dir fixed it:

# ./perl installman --man1dir=/home/ach/test/perl/man/man1 \
--man3dir=/home/ach/test/perl/man/man3
...

but a2p.1 and s2p.1 are still not installed. I will rerun Configure
tomorrow.

4) ===========
(Minor) suggestions for INSTALL file: In line 63 Configure example is
without a leading './' or 'sh '. I would also suggest to use only './'
or 'sh ' for the examples of {C,c}onfigure in INSTALL but not both.

Thanks to Larry and all the p5p,
Achim

P.S. configuration (with modified dec_osf hints file):

o01(0) ~/src/perl/perl5.002beta1 > ./perl -v

This is perl, version 5.002 beta

Copyright 1987-1995, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
o01(0) ~/src/perl/perl5.002beta1 > ./myconfig

Summary of my perl5 (patchlevel 2) configuration:
Platform:
osname=dec_osf, osver=3.2, archname=alpha-dec_osf
uname='osf1 o01 v3.2 148 alpha '
hint=recommended
Compiler:
cc='cc', optimize='-O2 -Olimit 2900', ld='ld'
cppflags='-DSTANDARD_C -I/usr/local/include'
ccflags ='-DSTANDARD_C -I/usr/local/include'
ldflags =' -L/usr/local/lib'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
voidflags=15, castflags=0, d_casti32=define, d_castneg=define
intsize=4, alignbytes=8, usemymalloc=y, randbits=15
Libraries:
so=so
libpth=/usr/local/lib /usr/shlib /lib /usr/lib /usr/ccs/lib
libs=-lgdbm -ldbm -ldb -lm -lc -lbsd -lPW
libc=/usr/shlib/libc.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef
cccdlflags=' ', ccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -s -hidden -L/usr/local/lib'

Re: buglets on OSF/1 (Re: 5.002 beta 1) [ In reply to ]

doughera at lafcol

Nov 21, 1995, 7:58 PM

Post #2 of 5 (481 views)

Permalink

On Tue, 21 Nov 1995, Achim Bohnet wrote:

> 2) ===========
> Obviously I'm wrong but I thought that *DB* stuff would now be found in
> /usr/local/{lib,include} by default. But gdbm and db extentions are not
> build (no .c,.o... files in the ext/{DB_File,GDBM_File}).
> So it is not found by 'default' :-( :-(.

Ahh. You have stumbled across a subtle bug, and I'm not sure offhand how
to fix it.

The 'locinpth' stuff works only if $ccflags is empty when you enter that
part of Configure. Why? If ccflags is set, then presumably it was set
for a good reason. If it's from a previous run, we definitely want to
honor it. The user may have deliberately removed the
-I/usr/local/include, for example.

If it's from a hint file, it's a bit more problematic. I suppose a hint
file could have deliberately omitted specifying the -I stuff in order to
avoid some problematic area on a particular system.

You run into this because hints/dec_osf.sh predefines ccflags. I'm
suprised no one else has run into this. Maybe you're just more observant
:-).

Hmm. I'm not positive how best to fix this. I don't want to make it
impossible for a hint file to turn off the local includes.

Hmm. If overriding locincpth in a hints file works, maybe I'll key what
to do off whether you're using a hint file or a previous config.sh.

>
> -r--r--r-- 1 root bin 8214 Aug 25 01:37 /usr/local/include/db.h
> -rw-r--r-- 1 root staff 4655 Aug 25 02:28 /usr/local/include/gdbm.h
>
> Using the way INSTALL suggests
>
> # make clean
> # mv config.sh config.sh.old
> # ./Configure -des -Dprefix=/home/ach/test/perl \
> -Dlocincpth="/usr/local/include" -Dloclibpth="/usr/local/lib"

... will run into exactly the same problem, as you just found out.

Andy Dougherty doughera@lafcol.lafayette.edu

Re: buglets on OSF/1 (Re: 5.002 beta 1) [ In reply to ]

doughera at lafcol

Nov 21, 1995, 8:10 PM

Post #3 of 5 (478 views)

Permalink

On Tue, 21 Nov 1995, Achim Bohnet wrote:

> On OSF/1 V3.2C (OSF1 o01 V3.2 148 alpha) I got 4 buglets:

> 3) ===========
> Don't know if this is intended but '.perl installman' of make install
> ignores Configures -Dprefix=/home/ach/test/perl option and tries to
> install below /usr/local/man (wasn't /usr/local/perl5/man/man3 the default???)

This is actually long-standing dist behavior you're seeing, though I'm
beginning to question whether I want to keep it.

Here's the problem:

Some sites store local man pages in /usr/local/man/man[0-9].
Other sites store local man pages in /usr/local/man/manl
(that's a lower case 'L', not the number '1'). Which one
should Configure use? It gets even more confusing if
$prefix != /usr/local.

Here's the full list, in order, of directories where Configure
tries to place man pages:

$prefixexp/man/man1
$prefixexp/man/u_man/man1
$prefixexp/man/l_man/man1
/usr/local/man/man1
/opt/man/man1
/usr/man/manl
/usr/man/local/man1
/usr/man/l_man/man1
/usr/local/man/u_man/man1
/usr/local/man/l_man/man1
/usr/man/man.L

Configure tries to honor existing practice on the system. It
tries to put man pages where you typically put them on your
system.

Thus, if you had done
mkdir -p $prefix/man/man1 $prefix/man/man3
*before* running Configure, the man pages would have gone where you
wanted them.

I'm not sure how to fix this one either. It can lead to suprises
if perl is the first 'local' software you install on a machine, so that
the /usr/local/man* directories don't exist.

At the very least, however, I'm tempted, to create the man directories
under $prefix if $prefix contains the string 'perl', since you're then
going to have to modify your PATH to contain /opt/perl/bin (or
whatever) anyway, so you might as well have to set MANPATH.

GNU software always installs in $prefix/man/man? (even when it should
be $prefix/u_man/man1, or something similar). Maybe perl should be
a little more aggressive here.

Sorry to give such a long answer to such a short question, but
sometimes it helps me to think out loud.

Andy Dougherty doughera@lafcol.lafayette.edu

Re: buglets on OSF/1 (Re: 5.002 beta 1) [ In reply to ]

doughera at lafcol

Nov 21, 1995, 8:36 PM

Post #4 of 5 (479 views)

Permalink

Re: buglets on OSF/1 (Re: 5.002 beta 1) [ In reply to ]

bill at netagw

Nov 21, 1995, 9:17 PM

Post #5 of 5 (483 views)

Permalink

> Message ID: <Pine.3.89.9511212115.C2964-0100000@lafcol>
> From: Andy Dougherty <doughera@lafcol.lafayette.edu>
> Date: Tue Nov 21 20:10:34 1995
> Subject: Re: buglets on OSF/1 (Re: 5.002 beta 1)
> ------------------------------------------------------------
>
> Here's the problem:
>
> Some sites store local man pages in /usr/local/man/man[0-9].
> Other sites store local man pages in /usr/local/man/manl
> (that's a lower case 'L', not the number '1'). Which one
> should Configure use? It gets even more confusing if
> $prefix != /usr/local.

And then there are those that store man pages in:
/usr/local/man/man.[0-9]
/usr/local/man/man.l
etc. ^ note the period

...Bill
--
Bill Aten <bill@netagw.com> Member of UVV
==============================================================================
Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant;
the population is growing.