Date: Sun, 3 Feb 2008 17:18:40 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Static compilation On Thu, Jan 31, 2008 at 02:07:35PM +0000, fridzy padzy wrote: > I have to compil staticly john the ripper in order to make it work on another linux machine (which do not have the same librairies). This does not necessarily imply the need for static linking. As an alternative, you may compile JtR on the oldest of your Linux systems. Chances are that the same binary will also work on the rest of your machines. In fact, this is how I build JtR Pro for Linux/x86 - on an Owl 1.1 system, which uses glibc 2.1.3 (with lots of patches, but that should not matter in this context). Due to symbol versioning, the same binary works on systems with newer versions of glibc just fine. > Therefore, i tried to edit the Makefile and added the -static in the CFLAGS field ... but it doesn't look that easy :( For static linking, if that's what you want despite of my suggestion above, you need to add -static to LDFLAGS, not CFLAGS. > Actually, i've got the following error : > /home/fred/johnStatic/src/path.c:44: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > path.o(.text+0x67):/home/fred/johnStatic/src/path.c:45: warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking This is not an error, it is merely a warning. What it is trying to say is that your build of glibc does not fully support static linking - specifically, the Name Service Switch (NSS) will continue to load NSS modules dynamically, like it should, even when your application is statically linked with the rest of glibc. This is addressed in more detail in glibc documentation, which actually insists that distributions build glibc in this way, letting NSS work even from statically-linked programs. The only place where JtR uses a function that results in NSS calls (on glibc) is path.c: path_init() - and only when JtR is built with JOHN_SYSTEMWIDE enabled. This is because with system-wide installs, JtR needs to determine the invoking user's home directory path, and on glibc this is handled via NSS (such that NSS modules may be used to provide a different source for this kind of information). So, if you insist on static linking and you do not want to run into potential incompatibilities of other versions of NSS modules with your statically-linked version of glibc, then you need to disable JOHN_SYSTEMWIDE. This implies that you'll need to keep the "john" binary in the same directory with its data files, including ones that it writes into - just like it happens when "john" stays in the "run" directory after a local build. -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
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.