Re: dropbear and -lcrypt
On Sun, Jun 26, 2011 at 07:42:23PM -0500, Rob Landley wrote: 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. Yes, that was a bit unfortunate. I've attached a patch that should hopefully fix all of it (against 0.53.1). The rationale for the original (broken) change was so that only the dropbear binary would link -lcrypt, others don't need it. 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. Dropbear has used autoconf since the first public release in 2003*, mainly just for differences on non-Linux unixes. The build's a bit horrible, but that's all just GNU make. Rob's patch looks OK though anyway. Matt * http://cvs.ucc.asn.au/cgi-bin/viewvc.cgi/anoncvs/projects/dropbear/configure.in?revision=1.1view=markup
Re: dropbear and -lcrypt
On Thu, Jun 30, 2011 at 10:43:10PM +0800, Matt Johnston wrote: Yes, that was a bit unfortunate. I've attached a patch that Here's the patch, missed it. Matt # # old_revision [c7f6c45c46a2f8e2394756c68ae825d6e4dc7489] # # patch Makefile.in # from [ea21753734b01f01ea1062923f4cb5eac65eadec] #to [3dcc9b69742a8a4f59ea9f22b6d80bad2c761117] # --- Makefile.in ea21753734b01f01ea1062923f4cb5eac65eadec +++ Makefile.in 3dcc9b69742a8a4f59ea9f22b6d80bad2c761117 @@ -28,7 +28,7 @@ COMMONOBJS=dbutil.o buffer.o \ queue.o \ atomicio.o compat.o fake-rfc2553.o -SVROBJS=@CRYPTLIB@ svr-kex.o svr-algo.o svr-auth.o sshpty.o \ +SVROBJS=svr-kex.o svr-algo.o svr-auth.o sshpty.o \ svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o svr-session.o svr-service.o \ svr-chansession.o svr-runopts.o svr-agentfwd.o svr-main.o svr-x11fwd.o\ svr-tcpfwd.o svr-authpam.o @@ -56,7 +56,7 @@ HEADERS=options.h dbutil.h session.h pac loginrec.h atomicio.h x11fwd.h agentfwd.h tcpfwd.h compat.h \ listener.h fake-rfc2553.h -dropbearobjs=$(COMMONOBJS) $(CLISVROBJS) $(SVROBJS) +dropbearobjs=$(COMMONOBJS) $(CLISVROBJS) $(SVROBJS) @CRYPTLIB@ dbclientobjs=$(COMMONOBJS) $(CLISVROBJS) $(CLIOBJS) dropbearkeyobjs=$(COMMONOBJS) $(KEYOBJS) dropbearconvertobjs=$(COMMONOBJS) $(CONVERTOBJS) @@ -167,7 +167,7 @@ ifeq ($(MULTI),1) # multi-binary compilation. MULTIOBJS= ifeq ($(MULTI),1) - MULTIOBJS=dbmulti.o $(sort $(foreach prog, $(PROGRAMS), $($(prog)objs))) + MULTIOBJS=dbmulti.o $(sort $(foreach prog, $(PROGRAMS), $($(prog)objs))) @CRYPTLIB@ CFLAGS+=$(addprefix -DDBMULTI_, $(PROGRAMS)) -DDROPBEAR_MULTI endif
Re: dropbear and -lcrypt
On 06/30/2011 09:43 AM, Matt Johnston wrote: 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. Dropbear has used autoconf since the first public release in 2003*, mainly just for differences on non-Linux unixes. *shrug* Possibly the Linux build didn't use it in previous releases? (I remember you had to edit options by hand...) The build's a bit horrible, but that's all just GNU make. I've been talking with several people about trying to find some replacement for the giant harball of autoconf/automake/gmake/libtool the way git replaced CVS. Alas, the tool we need doesn't exist yet, and convincing a big project like Linux to switch over to provide an example to everybody else will be a hard sell if Linus Torvalds doesn't personally write said tool again... But we live in hope. :) Rob
Re: dropbear and -lcrypt
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 diff -ru dropbear-0.53.1/Makefile.in dropbear.new/Makefile.in --- dropbear-0.53.1/Makefile.in 2011-03-02 07:23:34.0 -0600 +++ dropbear.new/Makefile.in 2011-06-21 12:48:11.044303706 -0500 @@ -28,7 +28,7 @@ queue.o \ atomicio.o compat.o fake-rfc2553.o -SVROBJS=@CRYPTLIB@ svr-kex.o svr-algo.o svr-auth.o sshpty.o \ +SVROBJS=svr-kex.o svr-algo.o svr-auth.o sshpty.o \ svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o svr-session.o svr-service.o \ svr-chansession.o svr-runopts.o svr-agentfwd.o svr-main.o svr-x11fwd.o\ svr-tcpfwd.o svr-authpam.o @@ -77,7 +77,7 @@ INSTALL=@INSTALL@ CPPFLAGS=@CPPFLAGS@ CFLAGS+=-I. -I$(srcdir) $(CPPFLAGS) @CFLAGS@ -LIBS+=@LIBS@ +LIBS+=@LIBS@ @CRYPTLIB@ LDFLAGS=@LDFLAGS@ EXEEXT=@EXEEXT@
