i've nginx 1.5.8
If I check a config containing
cat sites/test.conf
...
location / {
proxy_pass http://VARNISH;
include includes/varnish.conf;
}
...
cat includes/varni
> Setting LD_LIBRARY_PATH in environment might work,
> please consult with your runtime linker documentation.
> Some runtime linkers allow you to override paths
> enforced by -rpath, see LD_LIBRARY_PATH_RPATH in
> http://man.freebsd.org/rtld for one such example.
> But this has nothing to do with n
oops. not quite ...
on systems where ld.so.conf does NOT point to the pcre path -- i.e, on
my production rather than dev boxes -- the RUNTIME link is incorrect,
ldd objs/nginx | egrep -i "pcre"
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x7fa719a0d000)
This can be remedied by rpath'in
> > > ./configure --with-cc-opt="-I/usr/local/include" \
> > > --with-ld-opt="-L/usr/local/lib64"
works as promised,
...
make
ldd objs/nginx | egrep -i pcre
libpcre.so.1 => /usr/local/lib64/libpcre.so.1
(0x7fc62c7e7000)
Thanks.
> That is, it's only appl
> As you already have libpcre installed, you don't need nginx to
> build it (and you don't need sources). If nginx isn't able to
> find the pcre itself, use something like this to tell where to
> look for headers and library:
>
> ./configure --with-cc-opt="-I/usr/local/include" \
>
> Of course any installed pcre instance can be used. Moreover,
> nginx will try hard to detect various standard installations, see
> lib/pcre/conf.
>
> The --with-pcre option was introduced to simplify building the
> library with nginx itself, which is sometimes practical,
> especially if the
On Tue, Dec 10, 2013, at 10:25 AM, Maxim Dounin wrote:
> > Right now, when PCRE is compiled from source via --with-pcre, there is
Is the --with-pcre option in nginx, pointing to path to pcre src files,
necessarily rebuilding pcre in/with the nginx build?
If we've got a locally configured/built/in
