Error when cross configuring openssh 4.2p1

[openssh at baker-net.org.uk]

On Tuesday 11 October 2005 23:24, Darren Tucker wrote:
> openssh at baker-net.org.uk wrote:
> > I see that lots of improvements have happened in cross configure support
> > compared to version 3.8p1 but a couple of problems remain
> >
> > 1) The check that openpty does not reacquire controlling terminal (line
> > 1326 in configure.ac)  does not have a default value - I ran the test on
> > my target and checked it was OK but I'm not sure what is the best default
> > for others.
> >
> > 2) The etc_default_login check at line 2973 in configure.ac attempts to
> > define a default behaviour but configure still fails unless you specify
> > --disable-etc-default-login
> >
> > I suspect at least the former is dependent on what target you are
> > building for, I'm building on a Suse 9.3 system for a
> > armv5b-softfloat-linux target.
>
> There's a patch for this here:
> http://bugzilla.mindrot.org/show_bug.cgi?id=1097
>
> I'm pretty sure it addresses #1, not sure about #2.
>
> If you can confirm that it works OK then we can apply it too.

I can confirm that it fixes the first problem but not the second. I've only 
tried building so far, not running but as I'm running a version I built by 
defaulting the first test I'm fairly confident this patch will behave the 
same.

I also noticed that the code to build/etc/ssh/ssh_prng_cmds  generates 
commands that work on the host rather than the target when cross compiling. 
This doesn't matter too much as it won't be used unless the user specifies 
--with-rand-helper as it is assumed SSLs PRNG is seeded internally for cross 
compiles but the failure mechanism isn't good - If I'm reading correctly any 
commands not supported on the target will just not be used for entropy 
generation potentially resulting in lower than expected entropy, possibly 
even completely predictable on small systems. As it isn't possible to 
generate this reliably when cross compiling the ideal option would be to 
force the user to supply a file of commands to use if it will be usedbut I'm 
happy to accept that may be too much effort to be worthwhile for a rare 
problem.

If you want a cross compile environment to test any future patches in then Dan 
Kegel's crosstool  (http://kegel.com/crosstool/) will build one for you 
fairly easily. I've tested it with Linux and cygwin hosts and heard reports 
of it working on OS/X  so I'd expect it to work on other BSD based OSs too.