[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: X Working!



On Thu, 17 Feb 2000, Chris McKillop wrote:
> On Thu, Feb 17, 2000 at 10:37:01AM -0500, Scott Bambrough wrote:
> > Scott Bambrough wrote:
> > > 
> > This if from the FAQ on netwinder.org:
> >  
> > SSH 1.2x versions require a bit of work to operate on the NetWinder. 
> > 
> 
> 	We (debian) are now using OpenSSH and not the original SSH.  Also,
> I am using kernel 2.2.12 under Debian with Unix98 pty's so I would assume
> that the code for pty control should work on both x86 and arm platforms.

Ok, I went and built OpenSSH and OpenSSL
	openssh-1.2pre17-1.src.rpm openssl-0.9.4-3_nw1.src.rpm
OpenSSL has a patch for ARM support from Marc Boucher

I did this on my NetWinder machines which have a versioned glibc (which
should make them almost identical to the same as what is in Debian ARM,
for the given problems)
	[root@stewart-nw11 marcbou]# rpm -q glibc gcc binutils kernel
	glibc-2.1.3pre3-1nw2_vers
	gcc-2.95.2-1nw1
	binutils-2.9.5.0.24-1
	kernel-2.2.13-20000131
Binutils has no patches, gcc has appropriate ARM patches, glibc has ARM
patches, which are now in the main glibc CVS tree.

glibc was built against the above listed kernel headers.

In "cat /proc/mounts" I have the following which is essentail:
	none /dev/pts devpts rw 0 0

My version of OpenSSH works fine.  I can ssh in and out of the box, the
only thing is it is not setting up X forwarding properly, might be a
config thing.  So I would assume that there is a problem somewhere in
Debian ARM, most likely with glibc.  Which kernel headers was glibc
compiled against?  This is generally where the pty problem has arisen from
in the past, or /dev/pts not being mounted.

> 	Hurm.  I do have openpty though...since gnome-terminal is using
> it just fine.  There are some differences between the DM's from Rebel and
> the Debian distribution.  What I think is the nice part about Debian is that
> we are actually using the same source and build process that is used on 
> every other platform (x86, sparc, m68k, alpha, powerpc, hurd).  My thought
> is that there is either a bug in the kernel support for Unix98 tty's or
> there is a bug in the C library on the arm.

My thoughts, which could be incorrect, are I would blame your current
version of glibc. It is possible that libc or kernel support for Unix98
tty's is broken, but I would say highly unlikely.  As I've been using them
fine on Titan since sometime early last year.  And they work fine in the
current DM stuff.

Have you tried a current, newly compiled version of glibc (either 2.1.2,
or 2.1.3 pre4)?  I can put one up if you are interested (in either rpm or
tar form), which will work on a Debian ARMv4l system.

As to why you think Debian is nice, I'll only say a short bit, and avoid
the really touchy/flameable parts.  It is nice that Debian uses the same
build process for all the platforms Debian currently supports.  The nicer
part is if all the "Debian" fixes get propogated back to the orignal
package maintainers, then everyone is a winner.  (I don't know if they do
this now, if so sorry for the false assumption.)

Now what really is a build process?  You grab a bunch of packages and
rebuild them on your machine.  It doesn't really matter what packageing
system you use, your packages should run on any binary compatible system
without much trouble.  If they do not, this is where bad fragmentation
comes in.  One person may have a few different patches in their tree,
which could cause problems.

My understanding of the Debian ARM port is it should run any binaries from
at least a current armv4l system.  Same as the Rebel DM 4.0 will be, and
what the current Titan VI is (both of which are/will have a versioned
glibc).

Sorry about that.  I may use RPM, try not to hold it against me :)  I'm
mainly here as I am interested in getting a current version of XFree86
3.3.6 running on ARM.  Ideally with optimization as well...

Later,
-Rms


Reply to: