[comp.lang.perl] random notes on patches 42 thru 44

rkrebs@archie.dsd.es.com (Randall Krebs) (01/13/91)

I just compiled perl patchlevel 44 on a sun3, a sun4, and a mips
computer.  Here are the problems I ran into.

When applying patch 42, there was a minor problem with the file
lib/ctime.pl.  The patch file wanted to see the following on line #13:

;#     $Date = do ctime(time);

But patchlevel 41 (or before) had already changed this line to:

;#     $Date = &ctime(time);

which is what patch 42 wanted to change it to.  Did that make sense?
I fixed it by changing "ctime.pl" to the old line and patching the
file with:

	cd lib; patch ctime.pl < ctime.pl.rej


The sun3 and sun4 went pretty smoothly.  We're still living in the
past with SunOS 4.0.3.  Configure made all the right guesses and the
test ran without error on the first try.  The mips wasn't so easy.

I tend to prefer the BSD compilation environment on the mips.  (For
those of you that don't have your own mips box to kick around, there
are native compilation environments and foreign compilation
environments.  Native is SYSV and foreign is BSD or POSIX.)  Configure
likes to browse through /usr/lib and /usr/include, but the real
information is in /bsd43/usr/lib and /bsd43/usr/include.  This makes
Configure guess wrong about "i_dirent" and "d_pwage" in config.sh.
I simply changed them from 'define' to 'undef'.

Also, the mips compiler hates the way that perl uses volatile.  I'm
not sure why, but I changed "d_volatile" to 'undef', too.  We're
running RISC/os 4.50.  If it's a compiler problem, maybe it will go
away someday.  I'd like to hear from anybody compiling perl with
volatile defined.

The test "op.stat" fails on subtests 36 and 37.  I'm pretty sure that
this is due to a RISC/os bug when accessing /dev/tty.  Other than
that, the other tests run successfully on the mips.

Here are a couple of enhancement requests for perl's configuration and
installation procedures:

   1)	Make the installation dependent on a make variable called
	DESTDIR.  This is how X is distributed and it makes some
	things very convenient.  Everywhere that a destination
	directory is referenced, it is preceded by the symbol DESTDIR.
	For instance, if I need to test the installation of perl
	without ruining the previously installed version, I could run:

		make DESTDIR=/tmp/test install

	Also, it would be nice if perl would create all the
	directories needed in the installation path (e.g.
	/tmp/test/usr/local/...)

   2)	Allow some options to have Configure look in non-standard
	places (e.g. /bsd43/usr/lib/libc.a) for libraries and header
	files.  Mips' schizophrenic development environment is kinda
	twisted, but anybody that can make Configure work for Eunice
	could probably handle mips, too.  And lastly,

   3)	"h2ph" ought to take command line arguments to override the
	source and destination directories.  I want to be able to do
	something like:

	   h2ph -d /tmp/test/usr/local/lib/perl /bsd43/usr/include/*.h

And by the way.  Thanks for the nice perl.  I'm definitely a
perl-junkie and you're definitely one of my net.heroes, Larry.

randall.
-- 
  Randall S. Krebs                  | "Friends don't let friends drive BMW's"
  (rkrebs@dsd.es.com)               |  
  Evans & Sutherland Computer Corp. |         - Harvey Shine
  Salt Lake City, Utah (Where?)     |  

meissner@osf.org (Michael Meissner) (01/13/91)

In article <1991Jan13.014908.3144@dsd.es.com> rkrebs@archie.dsd.es.com
(Randall Krebs) writes:

| Also, the mips compiler hates the way that perl uses volatile.  I'm
| not sure why, but I changed "d_volatile" to 'undef', too.  We're
| running RISC/os 4.50.  If it's a compiler problem, maybe it will go
| away someday.  I'd like to hear from anybody compiling perl with
| volatile defined.

I do (on a DECstation), but then I use GCC (with my patches :-) to
compile it.  I seem to remember that the MIPS people saying that
revision 2.20 of the compiler suite would finally be ANSI
complaint....
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?