openssh static build - mission impossible?
Peter Stuge
peter at stuge.se
Wed Mar 7 04:58:42 EST 2012
Mr Dash Four wrote:
>> ..multilib or no, the libcrypt.a being used is from /usr/lib and
>> since you say that this means armv7l then I don't think that is a
>> library you want to use on the armv6l target.
>
> Where did I say that my libcrypt.a is from armv7l?
I asked you what tuple you build with and you said armv7l, but that
turned out to be wrong; you're using armv5tel to build. It may be
running on an armv7l machine, but I asked in the context of the
parameters you were giving to configure, so it's all about the
toolchain here, not about the machine.
If your intention is indeed to build using the armv5tel compiler and
libraries then you probably shouldn't specify --build with armv7l.
When cross-compiling using autotools --host is what is most
important.
>> The compiler used having yet another tuple (armv5tel) doesn't
>> reduce potential problems and question marks.
>
> The compiler *never* used the armv5tel tuple as it wasn't specified
> anywhere!
It does use this tuple, because the tuple was specified when the
compiler was built, multilib or not. Look at the original output you
sent to the list and you'll find armv5tel mentioned.
> I have already told you that my compiler is multilib capable and the
> libcrypto.a in question is armv5tel,
Actually you didn't tell me this about libcrypto.a, I was told by the
compiler output.
> It is accepted by the compiler and there won't be any issues,
> because of the arch used (armv5tel can be run on armv6l machine
> without issues
Right, but then you aren't building with an armv6l tuple
cross-toolchain, so I would then also not use --host.
Normally when cross-compiling for a specific target, you also have a
specific toolchain for that target, as well as have built all system
libraries you want for that target which your package depends on.
It's clear now that you are using the unusual approach of trying to
reuse Fedora binaries for OpenSSH dependencies, in order to build
an OpenSSH binary targeted for a very different environment (bionic)
than Fedora. It's no surprise that this blows up in your face.
If you had been clear about your method you could have gotten the
following advice much sooner. I assumed you had taken the more
thorough approach, my bad.
You'll have much better success if you yourself build the
dependencies for OpenSSH. This is the usual way to build a
distribution. You only want to build OpenSSH and not a distribution,
but since you want the OpenSSH binary in a special way you
effectively must also build a small distribution (meaning in this
case a set of libraries) which allows building OpenSSH the way you
want. The Fedora binaries do not.
> You've "pointed" me to absolutely nothing of note
I'm sorry if you feel that I've wasted your time. Maybe you didn't
understand my advice.
> As I suggested in my previous post - if you are unwilling or
> incapable of contributing anything of substance, then don't
> bother replying.
That's not an excellent comment. You're overlooking the possibility
that I have given good advice which you misunderstood. I think you
may also overlook the right to free speech.
But I digress. If you refuse to build your own libcrypto then you
really have no way to accomplish your goal; the libcrypto you try
to use (Fedora's binary) has a dependency (NSS) which is incompatible
with your goal, leaving you the only choice of building your own, as
I suggested that you should already several emails ago. Did you check
already if OpenSSH actually includes a crypt() implementation in the
compat sources?
If it doesn't, then again I'd suggest to build your own small library
named, say, libmrdashfourcrypt which only includes a self-contained
crypt() implementation from one of the many sources of this function
available on the interwebs. You don't have to write it from scratch,
just copy a working implementation from a project with a compatible
license. The BSD projects come to mind, and there's also HelenOS.
Good luck! I hope you'll get it to work.
//Peter
More information about the openssh-unix-dev
mailing list