RE: OSF/1 binaries

Linus Torvalds (
Tue, 14 Nov 1995 16:20:47 +0200

"Ka'plaagh 14-Nov-1995 0954 +0000": "RE: OSF/1 binaries" (Nov 14, 11:03):
> > Steven,
> >
> > " Here at our school's computer labs we have a "spare" AlphaPC, one of
> > the 150 MHz variety, that a professor is no longer using. It used to run
> > NT. We have had a trying time getting this box to run OSF/1 3.0 to turn it
> > into a database server running Oracle. The firmware is out of date, and the
> > ROMs on the SCSI controller are so old that OSF/1 3.0 doesn't like booting.
> That's a Jensen and, yes it will boot Linux via the SRM console (in fact
> that's the only way that it will as there is no Milo for it.

Note that there is no X server available for the Jensen at this point.
I've been considering looking into exactly what the DEC X server needs
from the system, to see if I can make the DEC X server work under Linux,
but we'll see..

I did get far enough that I checked that the DEC X server actually
starts to run quite nicely and does the listen on the X sockets etc, but
it then started doing some OSF/1-specific ioctl calls (it did a
"workstation type query") which linux doesn't have, and it exited at
that point. _If_ the DEC X server does most of the actual work in user
space, and only uses the ioctl to actually ask what kind of display we
have, it might be possible to run that.

I'll see if I ever get any free time to look into this. I have the
Jensen here at the university now, but I haven't had much time to look
into this "secondary" issue..

> As for Digital Unix binaries running on Linux, right now only statically
> linked binaries will make the transition (both ways). However, should
> someone implement shared libraries in the same way that Digital Unix
> does it then even shared library images could swap. I did see a flurry
> of debate on this on the net but that seems to have dried up now...

I'd be _very_ interested if somebody has access to a Oracle/alpha
version, and tries that on top of linux. I suspect it may do some
license manager checking or similar, in which case it probably wouldn't
run, but other than that it might actually work. The worst problems I
have had with the few Digital UNIX binaries I've tested is the fact that
they usually assume a different filesystem layout than the one you'd
have on a pure linux machine (the /etc/svc.conf stuff that David M-T
also mentioned about the Arena web browser etc).

Of course, going the reverse way (running linux binaries on top of
Digital UNIX) doesn't necessarily work, as linux has a much saner
"getdents()" system call to read directories, for example ;-). But it
should work for _most_ programs, at least as long as we're doing only
statically linked programs.

I'd love to have dynamically linked binaries, and I'd personally be
happy if we could have them compatible with the Digital UNIX way of
doing things. But I don't see that as wery likely, due to nobody having
the quivalent of /sbin/loader etc on linux. I suspect that linux shared
libraries will either be ELF libraries like on the x86 platform or by
using the old "static" shared a.out-type libraries (using an ECOFF
header, probably: ECOFF really _is_ a.out as far as linux is concerned).