apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: [PATCH] for Bug #24664
Date Thu, 13 Nov 2003 10:37:39 GMT
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

Mime
View raw message