[rescue] compiling old software re: emacs on SunOS 4.1.4

[john]

You can probably divine that I don't know what I'm doing from these
notes, but...

I, too, use vi almost exclusively, not only on the Sparc10, but also the
half dozen RasberryPi's soldiering away at various tasks around the
house, and of course the Linux machines and spouse's damned AppleAir.

I still have a SPARCprinter1 - and it works too. I needed Ghostprint to
enable it to print stuff which NewsPrint couldn't handle. This meant
brining up GCC using the old resident 4.1.4 cc. This went pretty well
especially because notes I found on the web alerted me to potential
problems.B Eventually I got gcc 2.9.5 running and then ghostprint.B And
yes, the sparc10 is a print server which will print anything we send it
from linux or the apple.B I haven't been able to get windows 10 to deal
with it because I haven't figured out how to get the PPD info into some
form that the Windows printer routine can understand.

I then thought it would be nice if I could get VNC running on the
SPARC10.B I could display Xclock from the Sun on other machines, but
nothing more complex.B VNC would be nice, but I ran into a host of
dependency problems trying to compile it.

So my question is: Is it possible that when I try to compile what
purports to be 1995 vintage code, someone has doctored up the
configuration files to expect a more modern environment?B For example, I
was able to get GMAKE compiled, but then it didn't like my SED, and so I
tried updating SED and ran into other things it didn't like. It looked
like an endless treasure hunt. I gave up.

There is also the problem of patches and how far up one should bring a
system.B I decided to patch up to 2000, among other things so DATE would
work right. I would think I could run into trouble trying to compile
1995 code on a machine patched to 2000.

The original motivation for keeping the SS10 running was so I could run
a 1992 version of a solid modeling package i had a license for.B After
doing all sorts of upgrades and going to microSd drive and two ross
hypersparc processors and a whole lot of RAM, I decided it would be
better to work on a modern solid-modeler.B I subscribed to CREO, which
is quite good but runs on Windows 10.B Now, except for the printing, the
SS10 has nothing to do.B I would like to bring up VNC, but it looks like
a month's work and I don't have THAT much time.

as to crackerjack, there's a prize in there somewhere if only I can find it.

john
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Doug McIntyre]

On Tue, May 29, 2018 at 09:06:25AM -0400, john wrote:
> So my question is: Is it possible that when I try to compile what
> purports to be 1995 vintage code, someone has doctored up the
> configuration files to expect a more modern environment?B For example, I
> was able to get GMAKE compiled, but then it didn't like my SED, and so I
> tried updating SED and ran into other things it didn't like. It looked
> like an endless treasure hunt. I gave up.

As long as you get old enough distributions of the stock GNU code
bases, yes, you should be able to expect it to configure, compile and
run on SunOS v4.1.4 quite handily.

For quite some time, I would consider SunOS 4.1.4 the "reference" platform
for any of the open source software.

After a while, when SunOS usage was on the decline, and linux was
taking over, many linux-isms started creeping into the software
distributions making it more difficult to do things on either SunOS
or Solaris. And eventually, GNU software started dropping any
sort of pretense for being able to compile on SunOS, and support for
compiling there was dropped out.

I would say that 90% of the code out there could still compile on
SunOS (assuming it isn't something that would have to dig into the
kernel, such as perhaps htop, or something of that nature), if you
knew the proper library incantantions (ie. -lnsl -lsocket -lresolv
will get you a long way to getting more things done, perhaps some of
the UCB stuff).

> There is also the problem of patches and how far up one should bring a
> system.B I decided to patch up to 2000, among other things so DATE would
> work right. I would think I could run into trouble trying to compile
> 1995 code on a machine patched to 2000.

I doubt it. At worst you'll have things assuming they are say 1960 and
show up as 2060, or the funniest were things like 20160 or something like that.

But the compilation/library systems didn't change for y2k patching.
It was mostly assumptions based on a two digit year as to what century it was.
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Romain Dolbeau]

2018-05-29 16:25 GMT+02:00 Doug McIntyre <***@geeks.org>:
> I would say that 90% of the code out there could still compile on
> SunOS

Having tried to get a half-decent web browser in S7/S8 on v7 & v8
hardware, I strongly disagree.
Most OSS nowadays is heavily reliant on a multitude of libraries, many
of which are rife with linuxisms, or assume a much, much newer libc
with new functions.
They are also assuming that dereferencing a pointer is always OK,
without caring for data alignment - which is causing a lot of grief to
the Debian/sparc64 people among others.

Also - anything even indirectly reliant on recent C++ is pretty much a
no-go on v7/v8 HW, you need v8+/v9 - UltraSPARC, so no SunOS.
C++ requires some atomic updates, and the GCC interface (not sure
about the language itself) assumes an atomic fetch-and-add is
available.
Which doesn't exist in SPARC prior to v8+/v9. You can fake it with a
global lock (or a hashed lock, if you need ultimate speed on those hot
SM512 ;-) ) for intra-process locking (been there, done that), but for
inter-process it's a nightmare to emulate properly.

I love SPARC, but no matter how awesome the work of those who did make
parallel SPARC machine (yeah Solbourne!), the designer of SPARC didn't
properly specify the atomic instructions in v7/v8. You really, really
want atomic fetch-and-add in real life. Not that it was obvious at the
time - for a lock, SPARC has enough support.

Cordially,

--
Romain Dolbeau
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Stefan Skoglund]

tis 2018-05-29 klockan 19:49 +0200 skrev Romain Dolbeau:
> 2018-05-29 16:25 GMT+02:00 Doug McIntyre <***@geeks.org>:
> > I would say that 90% of the code out there could still compile on
> > SunOS
>
> Having tried to get a half-decent web browser in S7/S8 on v7 & v8
> hardware, I strongly disagree.
> Most OSS nowadays is heavily reliant on a multitude of libraries,
> many
> of which are rife with linuxisms, or assume a much, much newer libc
> with new functions.
> They are also assuming that dereferencing a pointer is always OK,
> without caring for data alignment - which is causing a lot of grief
> to
> the Debian/sparc64 people among others.
>
> Also - anything even indirectly reliant on recent C++ is pretty much
> a
> no-go on v7/v8 HW, you need v8+/v9 - UltraSPARC, so no SunOS.
> C++ requires some atomic updates, and the GCC interface (not sure
> about the language itself) assumes an atomic fetch-and-add is
> available.
> Which doesn't exist in SPARC prior to v8+/v9. You can fake it with a
> global lock (or a hashed lock, if you need ultimate speed on those
> hot
> SM512 ;-) ) for intra-process locking (been there, done that), but
> for
> inter-process it's a nightmare to emulate properly.
>
> I love SPARC, but no matter how awesome the work of those who did
> make
> parallel SPARC machine (yeah Solbourne!), the designer of SPARC
> didn't
> properly specify the atomic instructions in v7/v8. You really, really
> want atomic fetch-and-add in real life. Not that it was obvious at
> the
> time - for a lock, SPARC has enough support.
>
> Cordially,
>

ldstub (the atomic take-from-memory-deposit-in-register-store-a-value-
in-memory which doing bus-snooping) exists in supersparc (basically a
requirement for multiprocessor supersparc machines.)

C++ - a lot happened with regards to how to implement a lot of c++
semantics in the compilers around 1995-2000.

That web browsers from early 2000 is unworkable on sparcv8 and impotent
as a current web browser - well it says a lot of the changes in web
technologies between 1995 and 2008 or so
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Romain Dolbeau]

2018-05-31 22:23 GMT+02:00 Stefan Skoglund <***@agj.net>:
> ldstub (the atomic take-from-memory-deposit-in-register-store-a-value-
> in-memory which doing bus-snooping) exists in supersparc (basically a
> requirement for multiprocessor supersparc machines.)

'ldstub' is the "enough support" bit I was talking about. It's also in
v7, which is why you could have SM100 in the 600MP (and why Solbourne
could do their own MP systems before the 600MP with vanilla SPARC in
series 4 & 5).

But you really, really want 'cas' (introduced in v9) so that you can
do atomic increment as well, without the need for a separate lock
variable.
(a true atomic fetch-and-add is more efficient, but 'cas' will do).

Cordially,

--
Romain Dolbeau
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jonathan Patschke]

On Tue, 29 May 2018, john wrote:

> So my question is: Is it possible that when I try to compile what purports to
> be 1995 vintage code, someone has doctored up the configuration files to
> expect a more modern environment?B For example, I was able to get GMAKE
> compiled, but then it didn't like my SED, and so I tried updating SED and ran
> into other things it didn't like. It looked like an endless treasure hunt. I
> gave up.

For a while, GNU unofficially stood for "Get New Utilities" for that just
reason.

Back in the late 1990s, it was common to have a completely separate
userland utility/library tree just for GNU compatibility. /opt/fsf is a
pretty good place to put it. I could probably dig up my build notes from
back then (mentioning which order to build things, which configure option
to pass, etc.), but they'd target Solaris 2.6 rather than SunOS 4.1.4.

I still "get" to maintain one of these at the day job for our HP-UX 10
machines. There are inherent limitations to how modern the tools can be
when the kernel and libc and toolchain[0] are so ancient, but I was very
happy the day that I got GCC 5.2 working on it so that I could have almost
all[1] of C++14 at my command.


[0] Many of the 'binutils' tools don't support HP-UX 10, so we're stuck
with the many bugs and limitations in HP's ld, for instance.
[1] Forget about std::thread or Unicode support. HP-UX 10 still uses
"green" threads with some *really* weird semantics.
--
Jonathan Patschke
Austin, TX
USA
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Romain Dolbeau]

2018-05-29 17:55 GMT+02:00 Jonathan Patschke <***@celestrion.net>:
> Back in the late 1990s, it was common to have a completely separate
> userland utility/library tree just for GNU compatibility. /opt/fsf is a
> pretty good place to put it. I could probably dig up my build notes from
> back then (mentioning which order to build things, which configure option
> to pass, etc.), but they'd target Solaris 2.6 rather than SunOS 4.1.4.

If memory serves...

1) tar, distributed as a shell archive (.shar)
2) gzip, distributed as a compress'ed tar (.tar.Z)
3) gcc, in 4 stages (built-in cc is so bad, stage 2 and 3 differ, so
compare stage 3 and 4)
4) make

Then you should be mostly in the clear to build most of the GNU stuff
in the order you need them. You probably should rebuild tar/gzip with
gcc as well.
Of course with NFS you can simply extract the gcc source w/o
rebuilding tar & gzip, which simplify the problem.

GCC 2.7.2.3 should work on SunOS 4.1.4, though maybe with the crappy
cc you should start bootstrapping the process with a 2.6.x ...

Cordially,

--
Romain Dolbeau
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Romain Dolbeau]

2018-05-29 19:20 GMT+02:00 Romain Dolbeau <***@dolbeau.org>:
> 1) tar, distributed as a shell archive (.shar)
> 2) gzip, distributed as a compress'ed tar (.tar.Z)
> 3) gcc, in 4 stages (built-in cc is so bad, stage 2 and 3 differ, so
> compare stage 3 and 4)
> 4) make

I found some recompile I did a few years ago in qemu, and it seems the
order is a bit different.
gzip seems to be first, then tar, then I see bash and some utilities.
Only then gcc. Which
is weird, so I suspect there was multiple build on top of each other
to get converge to an
all-gcc build...

I have a 2.7.2.3 in there, but also a newer one:

-bash-3.2$ gcc-2.7.2.3 -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.4/2.7.2.3/specs
gcc version 2.7.2.3
-bash-3.2$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.4/2.95.3/specs
gcc version 2.95.3 20010315 (release)

I also see a build tree for 3.1.1 but no binary. Either this failed,
or I gave up before
qemu had the time to rebuild a 3.1.1... 2.95.3 could have been "good enough" :-)

Cordially,

--
Romain Dolbeau
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Andrew Jones]

The bbestb browser on hardware that old is probably Internet Explorer for UNIX.

Buggy, little or no CSS, but at least itbs fast

> On May 29, 2018, at 14:16, Romain Dolbeau <***@dolbeau.org> wrote:
>
> 2018-05-29 19:20 GMT+02:00 Romain Dolbeau <***@dolbeau.org>:
>> 1) tar, distributed as a shell archive (.shar)
>> 2) gzip, distributed as a compress'ed tar (.tar.Z)
>> 3) gcc, in 4 stages (built-in cc is so bad, stage 2 and 3 differ, so
>> compare stage 3 and 4)
>> 4) make
>
> I found some recompile I did a few years ago in qemu, and it seems the
> order is a bit different.
> gzip seems to be first, then tar, then I see bash and some utilities.
> Only then gcc. Which
> is weird, so I suspect there was multiple build on top of each other
> to get converge to an
> all-gcc build...
>
> I have a 2.7.2.3 in there, but also a newer one:
>
> -bash-3.2$ gcc-2.7.2.3 -v
> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.4/2.7.2.3/specs
> gcc version 2.7.2.3
> -bash-3.2$ gcc -v
> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.4/2.95.3/specs
> gcc version 2.95.3 20010315 (release)
>
> I also see a build tree for 3.1.1 but no binary. Either this failed,
> or I gave up before
> qemu had the time to rebuild a 3.1.1... 2.95.3 could have been "good enough" :-)
>
> Cordially,
>
> --
> Romain Dolbeau
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jonathan Patschke]

On Tue, 29 May 2018, Andrew Jones wrote:

> The bbestb browser on hardware that old is probably Internet Explorer for UNIX.

IE for Solaris was pretty darned good, as was IE for MacOS. It's truly a
shame that the Windows version was so awful.

These days, the only browsers I have patience for on old hardware are:

1. elinks
2. ssh -X ***@newer-posix-box firefox

Web "standards" advance too quickly to do most things with an old browser
that can't be done in lynx/links/elinks, and those "standards" come with
enough overhead[0] to crush older hardware.


[0] Someone formerly of this list once put it as: "Imagine how many
gigawatt-hours we could avoid using each year if we made some common
element of Javascript 5% more efficient." Both a fascinating and
depressing thing to consider.
--
Jonathan Patschke
Austin, TX
USA
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jerry Kemp]

Sorry for replying to old stuff.

Been out over the last week and I am catching up.

That said, Andrew and Jonathan, is this *really* your opinion? Or is the sarcasm just not making it across the Internet?

At least from my experience, and that of peer (sys admins), it was a horrible, nasty, buggy product that, we all suspected, merely
filled in a check box for m$, and was gone as quick as it appeared. We (sys admins) all quickly loaded it up, played with it a bit,
then just as quickly deleted it. Was working at a large oil exploration company at the time. Supporting hundreds of geologist at
the time (23 floors worth), all with SPARC Solaris based desktop's. God-help-us if any them had seen or knew about IE on Solaris's
existence and had asked for it.

One of the few products I don't keep a copy of in my (personal) archive. Nothing positive to say about it.

These comments where just funnies? Just missed 1 April by a bit? Right?

Jerry




On 29/05/2018 14:11, Andrew Jones wrote:
> The bbestb browser on hardware that old is probably Internet Explorer for UNIX.
>
> Buggy, little or no CSS, but at least itbs fast
>
....................................................................

On 29/05/2018 15:17, Jonathan Patschke wrote:
>
> IE for Solaris was pretty darned good, as was IE for MacOS.
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Stephen Conley]

Heh, Internet Exploder on Solaris was actually the only thing I can recall
running that *locked up* my Solaris machine back in the day (Sun SPARC 20
dual cpu, maxed out RAM, Solaris 2.6). It wasn't because it used too much
resources, it just did something that locked up the whole UI and at that
particular time I had no way to remote in and fix it so I had to hard
reboot it.

Of course, back then, I did the very stupid thing of being always logged in
as root, so that was probably part of it :) Made something poorly written
capable of bringing down the whole machine.


On Sun, Jun 3, 2018 at 3:32 AM, Jerry Kemp <***@oryx.us> wrote:

> Sorry for replying to old stuff.
>
> Been out over the last week and I am catching up.
>
> That said, Andrew and Jonathan, is this *really* your opinion? Or is the
> sarcasm just not making it across the Internet?
>
> At least from my experience, and that of peer (sys admins), it was a
> horrible, nasty, buggy product that, we all suspected, merely filled in a
> check box for m$, and was gone as quick as it appeared. We (sys admins)
> all quickly loaded it up, played with it a bit, then just as quickly
> deleted it. Was working at a large oil exploration company at the time.
> Supporting hundreds of geologist at the time (23 floors worth), all with
> SPARC Solaris based desktop's. God-help-us if any them had seen or knew
> about IE on Solaris's existence and had asked for it.
>
> One of the few products I don't keep a copy of in my (personal) archive.
> Nothing positive to say about it.
>
> These comments where just funnies? Just missed 1 April by a bit? Right?
>
> Jerry
>
>
>
>
> On 29/05/2018 14:11, Andrew Jones wrote:
>
>> The b bestb browser on hardware that old is probably Internet Explorer
>> for UNIX.
>>
>> Buggy, little or no CSS, but at least itb s fast
>>
>> ....................................................................
>
> On 29/05/2018 15:17, Jonathan Patschke wrote:
> >
> > IE for Solaris was pretty darned good, as was IE for MacOS.
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jonathan Patschke]

On Sun, 3 Jun 2018, Jerry Kemp wrote:

> That said, Andrew and Jonathan, is this *really* your opinion? Or is
> the sarcasm just not making it across the Internet?

It is really my opinion. I used IE for Solaris as my day-in, day-out
browser on an Ultra-1 for the duration of using that system. Unlike its
contemporary version of Netscape Communicator, it didn't often leave me in
the position of having to kill it to regain control of my mouse cursor.

Entirely too many of my Netscape sessions ended because I opened a menu at
some inopportune menu and couldn't click on anything in any application
thereafter.

> These comments where just funnies? Just missed 1 April by a bit?
> Right?

Nope. I ran Netscape and IE side-by-side while doing web development. IE
was slower and used a *lot* more memory, but Netscape more frequently
upended my whole workflow.

--
Jonathan Patschke
Austin, TX
USA
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Chris Hanson]

On May 29, 2018, at 10:20 AM, Romain Dolbeau <***@dolbeau.org> wrote:
>
> GCC 2.7.2.3 should work on SunOS 4.1.4, though maybe with the crappy
> cc you should start bootstrapping the process with a 2.6.x ...

You can go straight from stock cc on SunOS 4.1.4 to gcc 2.95.3 with only a
single modification: The file gcc/function.c will fail to compile because the
# in an #endif isnbt in the first column on a line. Fix that and you should
be able to fully bootstrap from a stock SunOS 4.1.4 installation.

-- Chris
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Richard]

Hi John

In stead of vnc I compiled X11R6 (long gnu journey from tar up...) for my SS20 rining 4.1.3U1 and then use Cigwyn X11 so my Windows 10 machine can be a X terminal. I can then setenv DISPLAY on the SS20 (or any other machine with X11 on it) to the Win10 machine and I have xterm, netscape, sunpc etc from the remote machines....

As others have pointed out also helps to go back and find age appropriate versions of the software. i.e. from the gnu archive. The current versions of sed/gcc/make etc really are a challenge on these old systems.

hope that helps.

Cheers

Richard

On Tue, 29 May 2018, at 11:06 PM, john wrote:
> You can probably divine that I don't know what I'm doing from these
> notes, but...
>
> I, too, use vi almost exclusively, not only on the Sparc10, but also the
> half dozen RasberryPi's soldiering away at various tasks around the
> house, and of course the Linux machines and spouse's damned AppleAir.
>
> I still have a SPARCprinter1 - and it works too. I needed Ghostprint to
> enable it to print stuff which NewsPrint couldn't handle. This meant
> brining up GCC using the old resident 4.1.4 cc. This went pretty well
> especially because notes I found on the web alerted me to potential
> problems.B Eventually I got gcc 2.9.5 running and then ghostprint.B And
> yes, the sparc10 is a print server which will print anything we send it
> from linux or the apple.B I haven't been able to get windows 10 to deal
> with it because I haven't figured out how to get the PPD info into some
> form that the Windows printer routine can understand.
>
> I then thought it would be nice if I could get VNC running on the
> SPARC10.B I could display Xclock from the Sun on other machines, but
> nothing more complex.B VNC would be nice, but I ran into a host of
> dependency problems trying to compile it.
>
> So my question is: Is it possible that when I try to compile what
> purports to be 1995 vintage code, someone has doctored up the
> configuration files to expect a more modern environment?B For example, I
> was able to get GMAKE compiled, but then it didn't like my SED, and so I
> tried updating SED and ran into other things it didn't like. It looked
> like an endless treasure hunt. I gave up.
>
> There is also the problem of patches and how far up one should bring a
> system.B I decided to patch up to 2000, among other things so DATE would
> work right. I would think I could run into trouble trying to compile
> 1995 code on a machine patched to 2000.
>
> The original motivation for keeping the SS10 running was so I could run
> a 1992 version of a solid modeling package i had a license for.B After
> doing all sorts of upgrades and going to microSd drive and two ross
> hypersparc processors and a whole lot of RAM, I decided it would be
> better to work on a modern solid-modeler.B I subscribed to CREO, which
> is quite good but runs on Windows 10.B Now, except for the printing, the
> SS10 has nothing to do.B I would like to bring up VNC, but it looks like
> a month's work and I don't have THAT much time.
>
> as to crackerjack, there's a prize in there somewhere if only I can find it.
>
> john
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jonathan Patschke]

On Wed, 30 May 2018, Richard wrote:

> In stead of vnc I compiled X11R6 (long gnu journey from tar up...) for
> my SS20 rining 4.1.3U1

That's the sort of endeavor that should cause a tap to pop out of the side
of the machine so that it can pour you a pint.

--
Jonathan Patschke
Austin, TX
USA
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue