openssh unix dev - Oct 2002 - openssh-3.4p1 built on Tru64 Unix 5.1a - bug with sftpd

Dear openssh-unix-dev;

   I recently downloaded the tarball openssh-3.4p1 and built it for my
Tru64 Unix ( OSF/1 ) 5.1a system. My configure statement is:

./configure --prefix=/usr/local/security/tools/openssh-3.4p1 \
--exec-prefix=/usr/local/security/tools/openssh-3.4p1 \
-with-ssl-dir=/usr/local/security/tools/openssl-0.9.6g \
-with-zlib-dir=/usr/local/compress/tools/zlib-1.1.3 \
-with-xauth=/usr/bin/X11/xauth \
-with-random=/usr/local/security/tools/openssh-3.4p1/etc/ssh_prng_cmds

   I am using GCC 3.2 to build. The OpenSSH compiles and installs and is
working, mostly.

   However I have two problems for which I cannot find help on the web.

   The most serious is with the sftp system. When I connect to the 
installed sftp-server from a client using sftp I cannot list the
remote directory using either ls or dir without the resulting list
looping endlessly. This occurs only when the directory on the server
is an auto-mounted dir ( and therefore a linked NFS mount). When the 
directory is a locally mounted filesystem, ls works just fine. Again,
my user dirs on the alphaserver are automounted from a filer. When
I sftp to the alpha and do an ls (for my automounted home) the list
loops endlessly. When I cd to an alphaserver local filesystem, ls
works fine.

    The second problem involves the loader library path to the shared
GNU c library libgcc_s.so.1. I set LD_LIBRARY_PATH to the location of
my GNU distribution:

     setenv LD_LIBRARY_PATH /usr/local/gnu/lib

I set path to include /usr/local/gnu/bin.

   configure finds gcc and the libraries and builds executables just fine,
but the resultant executables must have LD_LIBRARY_PATH set to work. -
i.e. I must setenv LD_LIBRARY_PATH /usr/local/gnu/lib to get sshd to boot,
and to use each executable ( ssh, scp, sftp, etc. ) I must set the LIBRARY
PATH. Also, since sftp is started from SSHD through the subsystem process,
it cannot start, since it is relying also on LD_LIBRARY_PATH which is not
necessarily set in the environment from which it starts. I got around
this by wrapping sftpd in a csh script which I then reference in the
sshd_config as the startup for the sftp subsystem.

   I tried using --with-ldflags and modifying the Makefile to find 
/usr/local/gnu/lib but without luck.

   I would really like to know how to build openssh for my alpha system
to produce binaries that had the libgcc_s.so.1 internally references.
I tried to build without using gcc at all - but when I run configure it
always complains and quits because it says it cannot map libgcc_s.so.1.
Even when I am compiling with cc and do not have any globals or paths
set for GNU.

   I trust it is useful information to the community that openssh-3.4p1
can be built and run and be (somewhat) useful on an Alpha.

   Would someone guide me in helping make this port better?

Thank You.
David L. Wade

**********************************************************************
David L. Wade                                EMail: David.Wade at gat.com
Senior Systems Programmer Analyst                     Ph. 858-455-3342
General Atomics                                       Fx. 858-455-2692
3550 General Atomics Court                San Diego, California  92121     
**********************************************************************
opinions, conclusions, or recommendations expressed above are my own
and do not necessarily represent the views of my employer.

David L. Wade wrote:
>   I recently downloaded the tarball openssh-3.4p1 and built it for my
>Tru64 Unix ( OSF/1 ) 5.1a system. My configure statement is:
[snip]
>   I am using GCC 3.2 to build. The OpenSSH compiles and installs and is
>working, mostly.
[snip]
>    The second problem involves the loader library path to the shared
>GNU c library libgcc_s.so.1. I set LD_LIBRARY_PATH to the location of
>my GNU distribution:
>
>     setenv LD_LIBRARY_PATH /usr/local/gnu/lib

David, I have GCC 3.1.1, and the shared libraries were installed in
/usr/local/lib, which is one of the default places for the loader to look.
Did things change for 3.2? As a workaround, you could create a softlink (ln
-s) from the files in /usr/local/gnu/lib to /user/local/lib.

However, I strongly recommend that you use the native cc compiler instead.
My experience with GCC on the Alpha architecture is that it does a bad job
of optimizing code and runs much slower, and tends to be buggy.

Also, don't forget that privsep doesn't work for Tru64 in this release.

David Potterveld
Argonne National Laboratory