Mailing List Archive

> But more importantly, alla sudden SDBM doesn't want to build:
>
> sh: -cd: not found

In the Makefile for SDBM_File/sdbm, look for this line:

subdirs ::
@ -cd sdbm && $(MAKE) all $(PASTHRU)

And get rid of the space between the "@" and the "-cd". That's a workaround.

Jeff

> From: Randy J Ray <rjray@lookout.ecte.uswc.uswest.com>
>
> First off, I was a little caught off-guard by the use of 9000/887 (as two
> levels of dirs) for the architecture-dependant path.

Including /'s in archname seems risky. Some code somewhere is bound to assume
that archname is always one directory level. I know I would have until I saw
this message!

Translation to - seems sensible.

Tim.

On Tue, 31 Oct 1995, Randy J Ray wrote:

> First off, I was a little caught off-guard by the use of 9000/887 (as two
> levels of dirs) for the architecture-dependant path.

Ahh. That's an artifact of how I merged (or mismerged) the hpux_9.sh
and hpux_10.sh files.

What *is* a good way to generate archname? Is archname=hpux sufficient,
or do we need to distinguish different models?

Andy Dougherty doughera@lafcol.lafayette.edu

Andy Dougherty wrote :
|| On Tue, 31 Oct 1995, Randy J Ray wrote:
||
|| > First off, I was a little caught off-guard by the use of 9000/887 (as two
|| > levels of dirs) for the architecture-dependant path.
||
|| Ahh. That's an artifact of how I merged (or mismerged) the hpux_9.sh
|| and hpux_10.sh files.
||
|| What *is* a good way to generate archname? Is archname=hpux sufficient,
|| or do we need to distinguish different models?

There is at least one discrepancy - programs compiled on HPUX 10
won't run on HPUX 9, so if you are going to run software in a
common archive on both, then it must be compiled on 9. (Perhaps
some programs compiled on 10 will run on 9, but certainly some
won't. I haven't looked into the details too closely, though,
just heard of the effect.)

--
Maybe we can fix reality one of these days. | John Macdonald
<- Larry Wall Carl Dichter -> | jmm@Elegant.COM
I'd be happy if we could just index it. |

> There is at least one discrepancy - programs compiled on HPUX 10
> won't run on HPUX 9, so if you are going to run software in a
> common archive on both, then it must be compiled on 9. (Perhaps
> some programs compiled on 10 will run on 9, but certainly some
> won't. I haven't looked into the details too closely, though,
> just heard of the effect.)

I *think* this is mostly true due to the massive renaming of the file system
to be more SVR4'ish. However, I think this is mostly true of many other OS'es.
If you upgrade, you might not be backward compatible.

Jeff

> What *is* a good way to generate archname? Is archname=hpux sufficient,
> or do we need to distinguish different models?

Just FYI, I think the reason it's "two-level" is because uname reports the
architecture type as "9000/715" (on my workstation). Unix interprets that
slash as a directory separator.

I've tended to use 9000/700-hpux and 9000/800-hpux, but it struck me recently
that that is the wrong differentiator. I think the real differentiator is
the PA-RISC 1.1/1.0 and Motorola architectures.

The program getcontext returns "PA-RISC1.1" as the context type for my
workstation, and should return "PA-RISC1.0" for older systems (see perlhp.pod
for a list of which ones). Unfortunately, the context types for Motorola
systems are a bit more arcane, reflecting the times when we made systems based
on the 68010 chip.

To summarize, I'd suggest further modifying the hints file to allow the
following three choices for archname:

PA-RISC1.1
PA-RISC1.0
HP-MC68K

Jeff

P.S. Of course, I just saw that we have PA-RISC 1.2 and 2.0 versions either
already out or coming out. That complicates things a bit. Okay, libraries
compiled for RISC level N should run on any platform equal to or higher than
N. Should this kind of searching be done in the HP-specific dynamic loader,
or should the distributor of the shared library also make symlinks in the
directories >N?

> To summarize, I'd suggest further modifying the hints file to allow the
> following three choices for archname:
>
> PA-RISC1.1
> PA-RISC1.0
> HP-MC68K

And just to followup on my own, I'll have the hints file determine this
automatically. Look for a patch soon.

Jeff

According to Jeff Okamoto:
> > There is at least one discrepancy - programs compiled on HPUX 10
> > won't run on HPUX 9 [...]
>
> I *think* this is mostly true due to the massive renaming of the file system
> to be more SVR4'ish.

That reminds me:

Q: How many programmers does it take to change a light bulb?
A: Only one -- but you can never change it back again.

--
Chip Salzenberg, aka <chs@nando.net>
"Hey, it's the Miss Alternate Universe Pageant!"
-- Crow T. Robot, MST3K: "Stranded In Space"

> From: Jeff Okamoto <okamoto@hpcc123.corp.hp.com>
>
> I've tended to use 9000/700-hpux and 9000/800-hpux, but it struck me recently
> that that is the wrong differentiator. I think the real differentiator is
> the PA-RISC 1.1/1.0 and Motorola architectures.

Exactly.

> P.S. Of course, I just saw that we have PA-RISC 1.2 and 2.0 versions either
> already out or coming out. That complicates things a bit. Okay, libraries
> compiled for RISC level N should run on any platform equal to or higher than
> N. Should this kind of searching be done in the HP-specific dynamic loader,
> or should the distributor of the shared library also make symlinks in the
> directories >N?

I'd suggest symlinks. Remember that it's only an issue when you rebuild
and reinstall perl. Any given perl binary will carry on using it's
builtin sense of archlib even after the o/s has been upgraded.
The management of perl binaries across minor o/s version upgrades
is probably a bigger issue.

Don't forget you can hand pick archname and archlib in Configure if need be.

Tim.

: According to Jeff Okamoto:
: > > There is at least one discrepancy - programs compiled on HPUX 10
: > > won't run on HPUX 9 [...]
: >
: > I *think* this is mostly true due to the massive renaming of the file system
: > to be more SVR4'ish.
:
: That reminds me:
:
: Q: How many programmers does it take to change a light bulb?
: A: Only one -- but you can never change it back again.

Q: How many Perl programmers does it take to change a light bulb?
A: How many different ways do you want it done?

Q: How many perl5-porters does it take to change a light bulb?
A: How many different ways *don't* you want it done?

:-)

Larry

> > First off, I was a little caught off-guard by the use of 9000/887 (as two
> > levels of dirs) for the architecture-dependant path.
>
> Including /'s in archname seems risky. Some code somewhere is bound to assume
> that archname is always one directory level. I know I would have until I saw
> this message!
>
> Translation to - seems sensible.

I suggest
tr -cs 'A-Za-z0-9\12' '_'
just to be safe. (Translates even '-' to '_', in case we someday meet
an archname starting with '-' :-)


Regards,

Hallvard

On Nov 1, 5:18pm, Larry Wall wrote:
> Subject: Re: HP/UX and the nature of programming
> : According to Jeff Okamoto:
> : > > There is at least one discrepancy - programs compiled on HPUX 10
> : > > won't run on HPUX 9 [...]
> : >
> : > I *think* this is mostly true due to the massive renaming of the file
system
> : > to be more SVR4'ish.
> :
> : That reminds me:
> :
> : Q: How many programmers does it take to change a light bulb?
> : A: Only one -- but you can never change it back again.
>
> Q: How many Perl programmers does it take to change a light bulb?
> A: How many different ways do you want it done?
>
> Q: How many perl5-porters does it take to change a light bulb?
> A: How many different ways *don't* you want it done?
>
> :-)
>
> Larry
>-- End of excerpt from Larry Wall

Q: How many clones of Larry Wall does it take to change a light bulb?
A: Only one -- but its already fixed in my version.

:-)

--
Mark Pease markp@vlsi-az.sps.mot.com
Motorola MIMS VLSI Technology Center Mark_Pease-RXYE40@email.mot.com
4625 S. Ash Ave. Suite 12 Mail Stop: AZ28 BB106
Tempe, AZ 85282-6762 Phone:(602)752-2725 Pager:401-6949 FAX:(602)752-2759
Co-Author (with Carl Dichter) of Software Engineering with Perl