Patches for compiling / using portable OpenSSH on FreeMiNT?

James A Morrison ja2morri at student.math.uwaterloo.ca
Tue Jun 11 01:22:00 EST 2002


   From: Ben Lindstrom <mouring at etoh.eviladmin.org>
   Cc: OpenSSH Development <openssh-unix-dev at mindrot.org>, <fnaumann at freemint.de>
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   Sender: openssh-unix-dev-admin at mindrot.org
   X-BeenThere: openssh-unix-dev at mindrot.org
   X-Mailman-Version: 2.0.8
   Precedence: bulk
   List-Help: <mailto:openssh-unix-dev-request at mindrot.org?subject=help>
   List-Post: <mailto:openssh-unix-dev at mindrot.org>
   List-Subscribe: <http://www.mindrot.org/mailman/listinfo/openssh-unix-dev>,
	   <mailto:openssh-unix-dev-request at mindrot.org?subject=subscribe>
   List-Id: Development of portable OpenSSH <openssh-unix-dev.mindrot.org>
   List-Unsubscribe: <http://www.mindrot.org/mailman/listinfo/openssh-unix-dev>,
	   <mailto:openssh-unix-dev-request at mindrot.org?subject=unsubscribe>
   List-Archive: <http://www.mindrot.org/pipermail/openssh-unix-dev/>
   Date: Mon, 10 Jun 2002 09:46:45 -0500 (CDT)



   On Mon, 10 Jun 2002, Thomas Binder wrote:

   > Hi!
   >
   > On Thu, Jun 06, 2002 at 09:27:33AM -0500, Ben Lindstrom wrote:
   > > Post them, people will comment.  If they are correct and
   > > acceptable.  We will merge them.  Otherwise we won't. =)
   >
   > OK, here we go. Attached are 12 patch files:
   >
   [..]
   >
   > 4. openssh-3.2.3p1-getopt.patch
   >
   > For some reason, GNU ld chokes on optind being multiply defined,
   > thus this patch prefixes all global variables in
   > openbsd-compat/getopt.c with BSD and adds corresponding macros to
   > defines.h
   >
   I assume your staticly compiling?  Others have had issues because of
   this since native getopt.c lacks 'optreset' concept, and sadly some
   misguided person put it in libc instead of it's own library or designing
   it a bit more intelligently.

   I'd like others to try this that are having static compile issues.  This
   may solve their problem also.

   > 5. openssh-3.2.3p1-inet_ntop.patch
   >
   > This patch will most probably no longer be necessary with the next
   > version of FreeMiNT's C library. The problem is that the header
   > files define inet_ntop(), but the library is actually missing the
   > function. Thus, configure correctly does not define
   > HAVE_INET_NTOP, but the system header's prototype for inet_ntop()
   > does not match the one in openbsd-compat/inet_ntop.[ch]
   >

	const char *
	inet_ntop(int af, const void *src, char *dst, size_t size);

   Every platform around me that has inet_ntop defined is set that way.
   Unless there is a very good reason to change it.  I'm inclined not
   to.


   > 6. openssh-3.2.3p1-Makefile.patch
   >
   > As FreeMiNT needs to maitain TOS compatibility, a program's stack
   > size needs to be set at runtime. The default stack size created by
   > the linker is too small for the recursion level of some of
   > OpenSSH's binaries (especially ssh-keygen), thus one needs to
   > "inject" a larger default stack size into the binaries using a
   > special binary utility.
   >
   > This patch adds the necessary calls to this utility, but
   > unfortunately, I've no idea on how to add these lines to
   > Makefile.in in a way that configure will only include them into
   > the final Makefile for FreeMiNT, not for other systems.
   >

   Make it a seperate target and follow how @NO_SFTP@ works.  Only issue your
   going to run into is maintaining that list since we can and do miss things
   if we don't run the OSes ourselves.

   [..]
   > 8. openssh-3.2.3p1-path_to_login.patch
   >
   > Not a really important patch, but nonetheless I think it's better
   > to assume /bin/login instead of /usr/bin/login if none is found a
   > configure time.
   >
   Won't happen.  Don't see a need in changing it.  If configure.ac can't
   find a login program then no matter what default we use is wrong.
   Changing it does not improve anything.

   > 9. openssh-3.2.3p1-scp.patch
   >
   > FreeMiNT cannot open() directories, thus this patch will fall back
   > to stat() if open() fails with EISDIR. Without that, recursive
   > copying won't work with FreeMiNT.
   >
   > 10. openssh-3.2.3p1-setrlimit.patch
   >
   > FreeMiNT cannot dump core, thus setrlimit(RLIMIT_CORE) correctly
   > (IMO) fails with EINVAL ("An invalid resource was specified").
   > This patch therefore allows setrlimit(RLIMIT_CORE) to fail with
   > EINVAL (but not with other error codes).
   >

   I need to let others comment on theses two.  I'm not very fond on how they
   are implemented.

   - Ben

 Looking at the error descriptions, in the glibc manual, it seems ENOTSUP would
be a better error to return for setrlimit(RLIMIT_CORE).  I think that ssh 
should work on systems that return ENOSYS or ENOTSUP, or those systems should 
be fixed so that setrlimit works.  Usually EINVAL is used when programs pass
invalid arguments to a function, so I don't think we should ever overlook a
EINVAL error.

 Here are the descriptions.
 - Macro: int EINVAL
     Invalid argument.  This is used to indicate various kinds of
     problems with passing the wrong argument to a library function.

 - Macro: int ENOTSUP
     Not supported.  A function returns this error when certain
     parameter values are valid, but the functionality they request is
     not available.  This can mean that the function does not implement
     a particular command or option value or flag bit at all.  For
     functions that operate on some object given in a parameter, such
     as a file descriptor or a port, it might instead mean that only
     _that specific object_ (file descriptor, port, etc.) is unable to
     support the other parameters given; different file descriptors
     might support different ranges of parameter values.

     If the entire function is not available at all in the
     implementation, it returns `ENOSYS' instead.

- Macro: int ENOSYS
     Function not implemented.  This indicates that the function called
     is not implemented at all, either in the C library itself or in the
     operating system.  When you get this error, you can be sure that
     this particular function will always fail with `ENOSYS' unless you
     install a new version of the C library or the operating system.





More information about the openssh-unix-dev mailing list