Date: Sat, 9 Oct 2010 22:33:57 -0400 From: "Robert Harris" <rs904c@...scape.net> To: <john-users@...ts.openwall.com> Subject: RE: Patch for Makefile, concerning Solaris x86 John Users, Ok. I made a patch to fix all the solaris make targets. They now use the new parameter LDFLAGS_SOLARIS. LDFLAGS_SOLARIS = -lrt -lnsl -lsocket. See the official patch page for the download. -Robert Harris -----Original Message----- From: Solar Designer [mailto:solar@...nwall.com] Sent: Saturday, October 09, 2010 1:03 PM To: john-users@...ts.openwall.com Subject: Re: [john-users] Patch for Makefile, concerning Solaris x86 On Sat, Oct 09, 2010 at 01:55:36AM -0400, Robert Harris wrote: > We does the tgtsnarf program do, anyway? On a network with Kerberos v4 or AFS, it obtains a TGT for later attack with KRB4_fmt.c. I doubt that it'd work for current deployments, though. Quite possibly, no one will ever use this anymore. I was in a "merge all patches into jumbo" mode when this got in. ;-) > Why is it only built in Solaris? It is built on all platforms, but the extra libraries are only needed on Solaris because having basic networking functions separated from libc into these libraries is Solaris-specific. > I purpose we either do this for each Solaris build item (What is a better > name for this?), I call them make targets. > Option 1) > (add the text "-lnsl -lsocket" to each Solaris build item's LDFLAGS) ... > LDFLAGS="$(LDFLAGS) -lrt -lnsl -lsocket" Right, that's what we were discussing so far. > or this for each Solaris item Option 2) > (create a new global variable for Solaris only, and use that in the LDFLAGS) > (Looks like you have a MARKOV LDFLAGS, why not a new one for Solaris?) You're missing the point behind LDFLAGS_MKV: it is program-specific, not target-specific. An equivalent would be LDFLAGS_TGTSNARF or LDFLAGS_NET (in case we ever have more programs requiring the networking functions), not LDFLAGS_SOLARIS. And you'd add this new LDFLAGS_TGTSNARF or LDFLAGS_NET to the build line for tgtsnarf, for all make targets (not only Solaris), but you'd define it to empty string by default and override it to the proper libs on Solaris. However, as I've mentioned in the previous message on this topic, there's little point in doing this because we already have a similar "problem" for -lcrypto and some other libs, which we're not solving. We could solve all of these, but it's not something to discuss (a possible discussion would be a waste of time; I'd rather make the changes on my own if I ever choose to do so). > LDFLAGS_SOLARIS = -lnsl -lsocket (New Global variable) > > solaris-x86-sse2-gcc: > $(LN) x86-sse.h arch.h > $(MAKE) $(PROJ) \ > JOHN_OBJS="$(JOHN_OBJS) c3_fmt.o solaris-x86.o x86-sse.o > sha1-mmx.o md5-mmx.o" \ > CFLAGS="$(CFLAGS) -DHAVE_CRYPT" \ > LDFLAGS="$(LDFLAGS_SOLARIS) -lrt" This is not substantially different from your Option 1. Also, -lrt is a Solaris-specific option as well, so it'd need to get into LDFLAGS_SOLARIS in your example. > Which do you prefer? Looks like either one works. Either is fine. They don't differ in what they achieve (unlike possible per-program LDFLAGS, which would actually result in differently-linked binaries). I'll let you choose between your Option 1 and a revision of your Option 2 where -lrt would go into LDFLAGS_SOLARIS as well. Thanks, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.