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
Hello!
On Wed, Dec 11, 2013 at 07:01:38AM -0800, r...@sent.com wrote:
> > 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 an
> 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" \
>
Hello!
On Tue, Dec 10, 2013 at 11:08:03AM -0800, r...@sent.com wrote:
> > 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 th
