[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
