openssh on NeXTstep

Ben Lindstrom mouring at
Wed Sep 24 00:24:29 EST 2003

On Tue, 23 Sep 2003, Michael Weiser wrote:

> On Mon, 22 Sep 2003, Ben Lindstrom wrote:
> > NeXT platform has really not been directly supported since 3.5. =)  I'm
> > surprised it even compiles since I've had to pull harddrives from my next
> > box to do SCSI card testing under my Ultra 10 sparc box.

> That's a pity - I've got two NeXTstep m68k boxes here which run quite
> smoothly.  If it's only access to a machine it's perhaps a possibility to
> run NeXTstep i386 in VMware or bochs. I used it in both and they work
> quite alright, although the NE2000 emulation of bochs doesn't work with
> the NeXTstep 3.3 NE2000 driver.

I have a nice 25mhz Slab sitting on a desk at home.. Access has never been
an issue.  It is willingness to baby the platform.  At 25mhz a build
takes around 15 - 20 minutes (assuming all goes well).  And it seems to
get worse. =)

I love my NeXT box.. I actually fell in love with the OS back seven years
ago when we placed our aging Sun Stations w/ Intel NeXT in a college lab I
maintained (they are all Linux boxes now).

> > Not sure why it would crash in mysignal()  that code had been pretty
> > constant.
> It still seems to have something to do with it since sshd comes up and
> complains about unfound keys when I comment the signal define in
> bsd-misc.h like:
> /* #define signal(a,b) mysignal(a,b) */
> What is the actual purpose of mysignal()? Is it safe to just remove that
> define? I've diff'ed openssh 3.7.1p1 against 3.6.1p2 and found that in
> some places mysignal was replaced by signal and in others the other way
> round. Also the above define was added. *confused shrug*

No we can't remove it.  It actually is there for a very good reason.
Partly to solve issues with different singal() versions.  mysignal() is
suppose to be an extremely strict version of signal().  In a few spots of
our code we have needed it.  Between 3.6.1 and now we decided to use
mysignal() by default for every signal() in our tree.

I knew it would cause some breakage on platforms. =)  Just was not sure

It would be nice to know what signal() location it is causing the
behavior.  Maybe a backtrace from gdb and server side -ddd reports.

If it is tripping over a single instance.. Then we can handle it for that

It also be nice to see a copy of your config.

I am planning on getting a new "NeXT" laptop in a few months.. Oddly
enough they mispelt the name of it.. It has "Apple" written on it.

- Ben

More information about the openssh-unix-dev mailing list