Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 13 Nov 2003 10:37:39 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: [PATCH] for Bug #24664
Message-ID: <20031113103739.GA28412@redhat.com>
Mail-Followup-To: Joe Orton <jorton@redhat.com>, dev@apr.apache.org
References: <20031113011744.340b87fa.nd@perlig.de>
 <35720000.1068686754@scotch.ics.uci.edu>
 <20031113084658.0f8eb75d.nd@perlig.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20031113084658.0f8eb75d.nd@perlig.de>
User-Agent: Mutt/1.4.1i

On Thu, Nov 13, 2003 at 08:46:58AM +0100, Andr� Malo wrote:
> * Justin Erenkrantz <justin@erenkrantz.com> wrote:
> 
> > --On Thursday, November 13, 2003 01:17:44 +0100 Andr� Malo <nd@perlig.de> 
> > wrote:
> > 
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24664
> > >
> > > It seems, that on these GNU systems there's just a /lib/libcrypto.so.1.
> > > The attached patch looks just for this file if -lcrypt doesn't work.
> > > Looks a bit ugly, though it works fine in my tests.
> > 
> > Why isn't the linker picking up on it?  The second argument to 
> > AC_SEARCH_LIBS tells what -l combinations to try (first crypt, then ufc). 
> > So, autoconf should be trying -lcrypt if it doesn't find crypt() with the 
> > current combination of libraries.
> > 
> > So, what exactly is the failure mode here?  -- justin
> 
> I meant libcrypt without o, btw ;-)
> However the problem ist the number designation. If there's a link libcrypt.so
> -> libcrypt.so.1 it works without the hack.

If there is no such link, then you can't link anything against that
library, end of story.  I presume you only reproduced this by removing
the symlink?

The libfoo.so.N filenames are only used directly by the run-time linker,
they correspond to the soname which is extracted from reading
"libfoo.so" at compile-time.

joe