Bug #4006 for perl5: OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

# Wed, 30 Aug 2000 06:52:29 -0700 Alan Burlison <alanbur@mower.uk.sun.com> - Ticket created [Reply] [Comment]

Date:	Wed, 30 Aug 2000 21:51:58 +0100 (BST)
From:	Alan Burlison <alanbur [...] mower.uk.sun.com>
To:	perlbug [...] perl.org
Subject:	OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 3.1k

This is a success report for perl from Alan.Burlison@uk.sun.com, generated with the help of perlbug 1.32 running under perl v5.7.0. Built with -Uuse64bitint Perl reported to build OK on this system. BUT: it still appears to pick of all sorts of cruft on the library front: What libraries to use? [-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec] libsec is for ACL fiddling - does perl actually use it? --- Flags: category=install severity=none --- Site configuration information for perl v5.7.0: Configured by alanbur at Wed Aug 30 18:16:17 BST 2000. Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos mower 5.8 generic_108528-02 sun4u sparc sunw,ultra-60 ' config_args='-dsOE -Dprefix=/home1/software/perl/bldtest -Dinstallprefix=/home1/software/perl/bldtest -Dsiteprefix=/home1/software/perl/bldtest -Doptimize=-g -Duseshrplib -Uusemymalloc -Dusedevel -Ubincompat5005 -Uuse64bitint -Accflags=-DDL_UNLOAD_ALL_AT_EXIT' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-g', gccversion=, gccosandvers= cppflags='-DDL_UNLOAD_ALL_AT_EXIT -DDEBUGGING -I/usr/local/include' ccflags ='-DDL_UNLOAD_ALL_AT_EXIT -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib -L/opt/SUNWspro/WS6/lib ' libpth=/usr/local/lib /opt/SUNWspro/WS6/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -R /home1/software/perl/bldtest/lib/5.7.0/sun4-solaris/CORE' cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib -L/opt/SUNWspro/WS6/lib' Locally applied patches: DEVEL6918 --- @INC for perl v5.7.0: /home1/software/perl/build/perl/lib /home1/software/perl/bldtest/lib/5.7.0/sun4-solaris /home1/software/perl/bldtest/lib/5.7.0 /home1/software/perl/bldtest/lib/site_perl/5.7.0/sun4-solaris /home1/software/perl/bldtest/lib/site_perl/5.7.0 /home1/software/perl/bldtest/lib/site_perl . --- Environment for perl v5.7.0: HOME=/homedir/rootal LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH=/home1/software/perl/build/perl LOGDIR (unset) PATH=/homedir/rootal/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/opt/SUNWspro/bin:/usr/ccs/bin:/opt/gcc/bin:/usr/ucb:/usr/dt/bin:/usr/openwin/bin:/opt/SUNWisdn/bin:/opt/SUNWisdn/tools:. PERL_BADLANG (unset) SHELL=/bin/ksh Additional info: Compiler version.

# Wed, 30 Aug 2000 06:59:30 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Wed, 30 Aug 2000 15:59:24 -0500
From:	Jarkko Hietaniemi <jhi [...] iki.fi>
To:	Alan.Burlison [...] uk.sun.com
Cc:	perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 672b

On Wed, Aug 30, 2000 at 09:51:58PM +0100, Alan Burlison wrote: Show quoted text

> > This is a success report for perl from Alan.Burlison@uk.sun.com, > generated with the help of perlbug 1.32 running under perl v5.7.0. > > Built with -Uuse64bitint > > Perl reported to build OK on this system. > > BUT: it still appears to pick of all sorts of cruft on the library front: > > What libraries to use? [-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec] > > libsec is for ACL fiddling - does perl actually use it?

In Solaris, probably not. IIRC some platform required it for the eaccess() code (see lib/filetest.pm, and pp_sys.c). Patches( ?:to weed out unnecessary libraries)? welcome.

# Wed, 30 Aug 2000 17:56:23 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Thu, 31 Aug 2000 09:16:04 +0200
From:	Lupe Christoph <lupe [...] lupe-christoph.de>
To:	Jarkko Hietaniemi <jhi [...] iki.fi>, Alan.Burlison [...] uk.sun.com
Cc:	perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 2.5k

On Wednesday, 2000-08-30 at 15:59:24 -0500, Jarkko Hietaniemi wrote: Show quoted text

> On Wed, Aug 30, 2000 at 09:51:58PM +0100, Alan Burlison wrote:

Show quoted text

> > BUT: it still appears to pick of all sorts of cruft on the library front:

Show quoted text

> > What libraries to use? [-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec]

Show quoted text

> > libsec is for ACL fiddling - does perl actually use it?

What is -lcrypt useful, anyway? crypt() is in -lc *and* -lcrypt. Building perl without -lcrypt works OK. The manpage libcrypt(3LIB) isn't exactly illuminating. Alan, can you tell if it is needed or not? Show quoted text

> In Solaris, probably not. IIRC some platform required it for the > eaccess() code (see lib/filetest.pm, and pp_sys.c).

Show quoted text

> Patches( ?:to weed out unnecessary libraries)? welcome.

Here is a patch, assuming we do not want -lcrypt: --- hints/solaris_2.sh.orig Wed Aug 30 15:55:48 2000 +++ hints/solaris_2.sh Thu Aug 31 09:11:07 2000 @@ -24,12 +24,12 @@ glibpth="$*" # Remove bad libraries. -lucb contains incompatible routines. -# -lld doesn't do anything useful. +# -lld, -lcrypt, and -lsec don't do anything useful. # -lmalloc can cause a problem with GNU CC & Solaris. Specifically, # libmalloc.a may allocate memory that is only 4 byte aligned, but # GNU CC on the Sparc assumes that doubles are 8 byte aligned. # Thanks to Hallvard B. Furuseth <h.b.furuseth@usit.uio.no> -set `echo " $libswanted " | sed -e 's@ ld @ @' -e 's@ malloc @ @' -e 's@ ucb @ @'` +set `echo " $libswanted " | sed -e 's@ ld @ @' -e 's@ malloc @ @' -e 's@ ucb @ @' -e 's@ crypt @ @' -e 's@ sec @ @'` libswanted="$*" # Look for architecture name. We want to suggest a useful default. Here is another one, that retains crypt: --- hints/solaris_2.sh.orig Wed Aug 30 15:55:48 2000 +++ hints/solaris_2.sh Thu Aug 31 09:14:36 2000 @@ -24,12 +24,12 @@ glibpth="$*" # Remove bad libraries. -lucb contains incompatible routines. -# -lld doesn't do anything useful. +# -lld and -lsec don't do anything useful. # -lmalloc can cause a problem with GNU CC & Solaris. Specifically, # libmalloc.a may allocate memory that is only 4 byte aligned, but # GNU CC on the Sparc assumes that doubles are 8 byte aligned. # Thanks to Hallvard B. Furuseth <h.b.furuseth@usit.uio.no> -set `echo " $libswanted " | sed -e 's@ ld @ @' -e 's@ malloc @ @' -e 's@ ucb @ @'` +set `echo " $libswanted " | sed -e 's@ ld @ @' -e 's@ malloc @ @' -e 's@ ucb @ @' -e 's@ sec @ @'` libswanted="$*" # Look for architecture name. We want to suggest a useful default. Want more of these? Just tell me, they're easy ;-) Lupe Christoph

# Wed, 30 Aug 2000 19:32:55 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Thu, 31 Aug 2000 10:32:24 +0100
From:	Alan Burlison <Alan.Burlison [...] uk.sun.com>
To:	Lupe Christoph <lupe [...] lupe-christoph.de>
Cc:	Jarkko Hietaniemi <jhi [...] iki.fi>, perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 518b

Lupe Christoph wrote: Show quoted text

> What is -lcrypt useful, anyway? crypt() is in -lc *and* -lcrypt. > Building perl without -lcrypt works OK. The manpage libcrypt(3LIB) > isn't exactly illuminating. > > Alan, can you tell if it is needed or not?

Depends if you want strong(er) encryption or not ;-) From a cursory peek at the source code, the versions in libc use the standard password algorithm, and the libcrypt ones use DES encryption - but only in the domestic version. The international libcrypt doesn't include DES.

# Wed, 30 Aug 2000 23:19:49 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Thu, 31 Aug 2000 08:19:37 -0500
From:	Jarkko Hietaniemi <jhi [...] iki.fi>
To:	Alan Burlison <Alan.Burlison [...] uk.sun.com>
Cc:	Lupe Christoph <lupe [...] lupe-christoph.de>, perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 795b

On Thu, Aug 31, 2000 at 10:32:24AM +0100, Alan Burlison wrote: Show quoted text

> Lupe Christoph wrote: >

> > What is -lcrypt useful, anyway? crypt() is in -lc *and* -lcrypt. > > Building perl without -lcrypt works OK. The manpage libcrypt(3LIB) > > isn't exactly illuminating. > > > > Alan, can you tell if it is needed or not?

> > Depends if you want strong(er) encryption or not ;-) From a cursory > peek at the source code, the versions in libc use the standard password > algorithm, and the libcrypt ones use DES encryption - but only in the > domestic version. The international libcrypt doesn't include DES.

So Configure should do a traceroute to www.sun.com and from the trace deduce whether we are 'domestic' or 'suspected terrorists', and based on that either drop or leave -lcrypt in place...

# Thu, 31 Aug 2000 00:56:26 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Thu, 31 Aug 2000 16:48:22 +0200
From:	Lupe Christoph <lupe [...] lupe-christoph.de>
To:	Alan Burlison <Alan.Burlison [...] uk.sun.com>
Cc:	Jarkko Hietaniemi <jhi [...] iki.fi>, perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 889b

On Thursday, 2000-08-31 at 10:32:24 +0100, Alan Burlison wrote: Show quoted text

> Lupe Christoph wrote:

Show quoted text

> > What is -lcrypt useful, anyway? crypt() is in -lc *and* -lcrypt. > > Building perl without -lcrypt works OK. The manpage libcrypt(3LIB) > > isn't exactly illuminating.

Show quoted text

> > Alan, can you tell if it is needed or not?

Show quoted text

> Depends if you want strong(er) encryption or not ;-) From a cursory > peek at the source code, the versions in libc use the standard password > algorithm, and the libcrypt ones use DES encryption - but only in the > domestic version. The international libcrypt doesn't include DES.

Does this mean the domestic libcrypt crypt() is *incompatible* to /etc/shadow? I believe the (shadow) password is always encrypted with DES. In the international version of Solaris, you can't *de*crypt. In any case, should we use the libc version of crypt() or the one from libcrypt? Lupe

# Thu, 31 Aug 2000 00:57:31 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Thu, 31 Aug 2000 15:55:47 +0100
From:	Alan Burlison <Alan.Burlison [...] uk.sun.com>
To:	Jarkko Hietaniemi <jhi [...] iki.fi>
Cc:	Lupe Christoph <lupe [...] lupe-christoph.de>, perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 739b

Jarkko Hietaniemi wrote: Show quoted text

> > Depends if you want strong(er) encryption or not ;-) From a cursory > > peek at the source code, the versions in libc use the standard password > > algorithm, and the libcrypt ones use DES encryption - but only in the > > domestic version. The international libcrypt doesn't include DES.

> > So Configure should do a traceroute to www.sun.com and from the > trace deduce whether we are 'domestic' or 'suspected terrorists', > and based on that either drop or leave -lcrypt in place...

Well, *we* already know where you are... Big Scott watching you ;-) Seriously, I think libcrypt should probably be left in - it certainly won't do any harm, irrespective of wether you are in God's Own Country or not.

# Thu, 31 Aug 2000 03:41:05 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Thu, 31 Aug 2000 18:40:18 +0100
From:	Alan Burlison <Alan.Burlison [...] uk.sun.com>
To:	Lupe Christoph <lupe [...] lupe-christoph.de>
Cc:	Jarkko Hietaniemi <jhi [...] iki.fi>, perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 388b

Lupe Christoph wrote: Show quoted text

> Does this mean the domestic libcrypt crypt() is *incompatible* to > /etc/shadow? I believe the (shadow) password is always encrypted > with DES. In the international version of Solaris, you can't *de*crypt. > In any case, should we use the libc version of crypt() or the one from > libcrypt?

Pass. I know next to nothing about this area - sorry. Alan Burlison

# Thu, 31 Aug 2000 04:29:08 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)
To:	Alan.Burlison [...] uk.sun.com
Cc:	Lupe Christoph <lupe [...] lupe-christoph.de>, perl5-porters [...] perl.org, Jarkko Hietaniemi <jhi [...] iki.fi>
From:	Nick Ing-Simmons <nick [...] ing-simmons.net>
Date:	Thu, 31 Aug 2000 18:18:19 +0000

Download (untitled) / with headers
text/plain 889b

Alan Burlison <Alan.Burlison@uk.sun.com> writes: Show quoted text

>Jarkko Hietaniemi wrote: >

>> > Depends if you want strong(er) encryption or not ;-) From a cursory >> > peek at the source code, the versions in libc use the standard password >> > algorithm, and the libcrypt ones use DES encryption - but only in the >> > domestic version. The international libcrypt doesn't include DES.

>> >> So Configure should do a traceroute to www.sun.com and from the >> trace deduce whether we are 'domestic' or 'suspected terrorists', >> and based on that either drop or leave -lcrypt in place...

> >Well, *we* already know where you are... Big Scott watching you ;-)

Which is all really silly - Jarkko is presumably still in Boston, and Alan has to shoot himself for looking at the source from the UK and hence exporting it ;-) As libcrypt already has the export-ery handled we may as well leave it in.

# Thu, 31 Aug 2000 09:14:22 -0700 The RT System itself - Correspondence added [Reply] [Comment]

Date:	Fri, 01 Sep 2000 00:13:27 +0100
From:	Alan Burlison <Alan.Burlison [...] uk.sun.com>
To:	Lupe Christoph <lupe [...] lupe-christoph.de>
Cc:	Jarkko Hietaniemi <jhi [...] iki.fi>, perl5-porters [...] perl.org
Subject:	Re: [ID 20000830.038] OK: perl v5.7.0 +DEVEL6918 on sun4-solaris 2.8 (UNINSTALLED)

Download (untitled) / with headers
text/plain 1.2k

Lupe Christoph wrote: Show quoted text

> > > What is -lcrypt useful, anyway? crypt() is in -lc *and* -lcrypt. > > > Building perl without -lcrypt works OK. The manpage libcrypt(3LIB) > > > isn't exactly illuminating.

>

> > > Alan, can you tell if it is needed or not?

>

> > Depends if you want strong(er) encryption or not ;-) From a cursory > > peek at the source code, the versions in libc use the standard password > > algorithm, and the libcrypt ones use DES encryption - but only in the > > domestic version. The international libcrypt doesn't include DES.

> > Does this mean the domestic libcrypt crypt() is *incompatible* to > /etc/shadow? I believe the (shadow) password is always encrypted > with DES. In the international version of Solaris, you can't *de*crypt. > > In any case, should we use the libc version of crypt() or the one from > libcrypt?

Further info on this. Seemingly /etc/shadow only uses DES if you fiddle with the PAM modules in /etc/pam.conf. I've tried a simple crypt() test linked to libc, libcrypt_i and libcrypt_d, and they all give the same output. libcrypt_d does indeed appear to have the decryption routines that are not in libcrypt_i. I think perhaps we should remove libcrypt after all. Alan Burlison