dropbear and -lcrypt

[Rob Landley]

On 03/15/2011 10:07 PM, Stuart Longland wrote:
> Hi,
> 
> Not sure what the cause was, but just today I was trying to compile
> dropbear against µClibc-0.9.31 on a mipsel system (native compile).  It
> would bomb out every time at the point where 'dropbear' is linked.

You're statically linking.

The problem with static linking is it does a single pass, grabbing
symbols out of the .a file that have pending references to them,
discarding all the symbols with no pending references.  The problem is:

A) If a symbol hasn't been referenced yet, it won't get grabbed even
though it was in the library.  (This is what you're seeing.)

B) if a symbol is available in more than one library, the different
versions can fight.  (This is why X11 last staticaly linked under the
Clinton administration.)

The 0.53 release of dropbear had -lcrypt symbols referenced in .o or .a
files _after_ libcrypt on the link command line.  Thus they were
unresolved, and the link failed.

I reported this here, and in response matt moved -lcrypt to the _start_
of the command line, before _anything_ references it, thus making the
-lcrypt into a NOP for static linking.  He then cut a 0.53.1 release
that _still_ didn't statically link, presumably without ever testing the
static linking fix.

I use the attached patch to build a static dropbear 0.53.1 in Aboriginal
Linux.  I have no idea if it's the _right_ fix because autoconf is an
abomination that dropbear didn't used to use, but which it got infected
by a few years ago for no obvious reason.

*shrug*

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-fixstatic.patch
Type: text/x-patch
Size: 760 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110626/b308d6c1/attachment.bin