On Tue, Dec 07, 2010 at 02:03:18PM -0500, Nick Mathewson wrote:
> On Mon, Dec 6, 2010 at 6:53 PM, Sanjeev Kulkarni <sanjeev@xxxxxxxxxxxxx> wrote:
> > Hey guys,
> > I'm a relative newbee to libevent so apologies if this is already answered.
> > How to configure libevent to use a non-standard installation path of
> > openssl. Basically my project has openssl included and I want libevent to
> > compile/link against that copy and not the standard system openssl.
> > Thanks!
>
> You should be able to just override the CPPFLAGS and LDFLAGS variable
> when you configure, so that they include the right -I and the right -L
> flags respectively.
>
> In 2.1, I'd like to adopt a more standard approach --possibly
> pkgconfig-- for other finding other libraries. But for now, that's
> what we've got.
Perhaps I don't understand pkg-config, but in my experience it's the exact
wrong solution to the problem of multiple libraries. pkg-config presumes a
single global installation. On my OS X laptop I keep each project and each
version of a project under different trees in /usr/local; e.g.
/usr/local/foo1.0, /usr/local/foo1.3. On other boxes I do the same under
$HOME/local.
That means that the pkg-config in one tree has no idea about the pkg-config
config in the other trees. I have to hack every dumb package that relies on
pkg-config in order to get it to build against--or even find--the correct
libraries, especially when it relies on pkg-config to find more than one
library.
The inventors of pkg-config must be like 12 years old because clearly they
don't remember the good/bad old days of users juggling package trees from
their user accounts. They must be using a different VM for each development
environment (or more likely, they do neither and presume all the world
relies on .deb, .rpm, or ports tree). What's wrong w/ the usual
`--with-libssl=/path/to/ssl/tree', or even `--with-libssl-include=' and
`--with-libssl-lib='?
PKG_CONFIG_PATH="/usr/local/foo1.0/lib/pkgdir" ./configure