Hi Peter:
What you wrote seems clear to me. However, let me describe
the host and target environment again to insure we understand
each other.
The GNL ELF tool chain is used to cross-compile the target executable,
which includes the entire UC Linux OS, and the applications
in the host environment. The executable is then converted into
an S19 format file and downloaded to the target environment.
The host is just an i686 Debian Linux system.
The target is an M5249 Coldfire processor.
The important target settings are as follows:
ARCH=m68knommu
CROSS_COMPILE=m68k-elf-
Does this make sense to you ?
Best Regards,
Paul R.
Peter Stuge wrote:
> Hi Paul,
>
> Paul Romero wrote:
> > First, thank you for the quick and detailed reply and be assured
> > the difference between SSH and SASL is clear to me.
>
> Great!
>
> > Also, I must emphasize that my interest is in the SSH-2 component
> > subset required to support SFTP rather than SSH.
>
> Ah, sorry for being a bit sloppy with terminology. These days SSH
> version 1 is not in wide use anymore, so I tend to put SSH = SSH
> version 2 always. libssh2 only supports SSH version 2.
>
> > I think the SASL version of libgcrypt meets the minimum libssh2
> > requirements, and that AES and RIJNDAEL are the same.
>
> That's correct.
>
> > Also, I assume that libssh2 can use DES and 3DES interchangeably.
>
> They are distinct algorithms, and SSH requires 3DES. Several
> algorithms are OPTIONAL in the standard, including AES/RIJNDAEL,
> although it is listed as RECOMMENDED and aes128-ctr, aes192-ctr and
> aes256-ctr is likely to become REQUIRED in the future so I always
> strongly recommend that they be included.
>
> > It appears most SFTP implementations also use the following:
> > Diffie Hellman-SHA1, Blowfish, Twofish, HMAC-SHA1 and HMAC-MD5.
> > Do you think that is correct ?
>
> DH-SHA1 and HMAC-SHA1 are also REQUIRED, the others are optional. SSH
> handles negotiation at connect time to the prefered algorithms
> supported by both client and server.
>
> > The reason I mentioned SASL is the version GSASL I am using came with
> > a version of libgcrypt. However, I am not sure if libgcrypt is part
> > of the GSASL package or it came from elsewhere.
>
> libgcrypt is always it's own package. Good news.
>
> > In any case, assuming a version of libgcrypt that supplies what
> > libssh2 needs is found, libssh2 and libgcrypt can easily be linked
> > together. Is that correct ?
>
> Yes, you select if you want to use libgcrypt or OpenSSL when you run
> configure for libssh2.
>
> > You seem to suggest that compiling libssh2 requires modern automake
> > capabilities.
>
> I don't think it does actually, and even if it did, I wanted to point
> out that it's not a problem, since autotools are not a part of the
> toolchain and could thus be updated to the very latest version
> without problems, should that be required.
>
> > Using a newer version of the GNU ELF Toolchain may solve that
> > problem for me--cross compilers etc. But, migrating to a newer
> > UC Linux version is not an option. Would this be a barrier to using
> > libssh2 ?
>
> No. As long as you have a working GNU toolchain for your target and
> a sane /bin/sh then you will be fine.
>
> > (i.e. I am sure the GNU toolchain I am using does not have modern
> > automake capabilities.)
>
> Again, please don't connect those two. autotools (slang for
> autoconf+automake) is independent, only ever required natively on the
> host machine, and actually you don't need it unless you want to try
> to build libssh2 with your own source code modifications.
>
> > Note that the UC Linux Makefile scheme, and where and how
> > libraries are linked is quite different than in standard Linux.
>
> The binaries and libraries, which is what matters for libssh2, are
> quite likely built using totally standard cross-compiler techniques,
> since you have a GNU toolchain. That's really the only point that
> matters.
>
> > In addition there are differences in how forking and exits work
> > despite the fact the kernel API is the same.
>
> True! However libssh2 never forks, so no issue.
>
> > Most of the "porting" I mentioned consists of creating Makefiles
> > that fit within the UC Linux scheme which is not a huge effort but
> > certainly not trivial.
>
> I don't know what these special Makefiles are that you mention, and I
> believe that you can simply cross-compile libssh2 using your
> toolchain for this target, in the standard way.
>
> Make sure the toolchain programs are included in your PATH, and use
> the --host=tuple parameter when configuring libssh2. Substitute tuple
> with the prefix for your toolchain, so if your toolchain provides
> m68k-elf-gcc, then run configure --host=m68k-elf and include the
> library paths needed.
>
> I recently described how I successfuly cross-compiled libssh2 for
> Windows and you can use the same procedure if you substitute my
> i686-mingw32 for m68k-elf or the appropriate prefix, and of course
> the paths to where your libraries and headers are.
>
> http://www.libssh2.org/mail/libssh2-devel-archive-2010-06/0155.shtml
>
> //Peter
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
-- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: paulr_at_rcom-software.com _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2010-07-02