upgrade apache-2.2.20 -> 2.2.21

[Jeremy Chadwick]

On Wed, Sep 21, 2011 at 09:27:19AM +0200, olli hauer wrote:
> On 2011-09-21 07:41, Jeremy Chadwick wrote:
> > On Wed, Sep 21, 2011 at 07:23:17AM +0200, Olli Hauer wrote:
> >> On 2011-09-21 06:43, n dhert wrote:
> >>> Hi,
> >>>
> >>> this is the output:
> >>>
> >>> ]$  ldd /usr/local/libexec/apache22/libphp5.so
> >>> /usr/local/libexec/apache22/libphp5.so:
> >>>         libcrypt.so.5 => /lib/libcrypt.so.5 (0x800889000)
> >>>         librt.so.1 => /usr/lib/librt.so.1 (0x800fcd000)
> >>>         libm.so.5 => /lib/libm.so.5 (0x8010d2000)
> >>>         libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x8011f2000)
> >>>         libz.so.5 => /lib/libz.so.5 (0x80143e000)
> >>>         libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801553000)
> >>>         libc.so.7 => /lib/libc.so.7 (0x800647000)
> >>> $ ldd /usr/local/bin/php*
> >>> /usr/local/bin/php:
> >>>         libcrypt.so.5 => /lib/libcrypt.so.5 (0x800855000)
> >>>         librt.so.1 => /usr/lib/librt.so.1 (0x80096e000)
> >>>         libm.so.5 => /lib/libm.so.5 (0x800a73000)
> >>>         libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x800b93000)
> >>>         libz.so.5 => /lib/libz.so.5 (0x800ddf000)
> >>>         libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800ef4000)
> >>>         libc.so.7 => /lib/libc.so.7 (0x8010ee000)
> >>> /usr/local/bin/php-cgi:
> >>>         libcrypt.so.5 => /lib/libcrypt.so.5 (0x800858000)
> >>>         librt.so.1 => /usr/lib/librt.so.1 (0x800971000)
> >>>         libm.so.5 => /lib/libm.so.5 (0x800a76000)
> >>>         libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x800b96000)
> >>>         libz.so.5 => /lib/libz.so.5 (0x800de2000)
> >>>         libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800ef7000)
> >>>         libc.so.7 => /lib/libc.so.7 (0x8010f1000)
> >>> ldd: /usr/local/bin/php-config: not a dynamic executable
> >>> ldd: /usr/local/bin/phpize: not a dynamic executable
> >>> I guess this is normal?
> >>>
> >>
> >> I'm missing pcre.
> >>
> >> If this is lang/php5, then pcre is a default LIB dependency and
> >> the output should have a line like this.
> >>
> >>  libpcre.so.0 => /usr/local/lib/libpcre.so.0
> > 
> > Incorrect.
> > 
> > For PHP, PCRE is included within the PHP core **STATICALLY** (but keep
> > reading).  This is INTENTIONAL.  You will not see it in ldd output.  You
> > can verify this using "objdump -x /usr/local/bin/php | grep -i pcre" if
> > you think I'm mouth and trousers.
> > 
> > For Apache, PCRE is linked DYNAMICALLY within httpd itself.
> > Verification:
> > 
> > # ldd /usr/local/sbin/httpd | grep -i pcre
> >         libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0xa07ba000)
> > 
> 
> 
> Hm, thats strange, since in lang/php5 we can find the following lines
>
> {snipping for brevity}

Okay I see what's going on here.  We've all made some mistakes within
this thread (myself included, happy/glad to admit that!).  The short
version is this (as of this writing/date):

- lang/php5 (PHP 5.3.8) builds its own version of PCRE that comes with
  PHP, and includes it statically.  It is therefore available at all
  times (php -i confirms), but obviously will not show up in ldd.  There
  is no framework for using devel/pcre instead of the built-in PCRE,
  and this is intentional; there is no stub port for PCRE nor any
  BUNDLED_PCRE option (keep reading).

- lang/php52 (PHP 5.2.17) *does not* include PCRE support by default.
  You are required to install devel/php52-pcre to get such support.

- lang/php52-pcre is a stub port of lang/php52.  lang/php52/Makefile.ext
  uses the Mk/bsd.php.mk framework to set PHP_MODNAME to "pcre" when
  building said stub port.  Why this is important:

  This stub port supports an OPTION called BUNDLED_PCRE, which defines
  whether or not you want to use the PCRE included with the PHP source
  code.  The default value for this OPTION is false/off (e.g.
  WITHOUT_BUNDLED_PCRE=true), which means lang/php52-pcre becomes
  dependent upon the devel/pcre port.

  You're supposed to set WITH_BUNDLED_PCRE (not a typo!) to true if
  you use Apache 2.0.x, but not if you use 2.2.x or otherwise.  I
  believe this may be because of namespace or symbol name collisions?
  I'm really not sure what the justification is; I imagine the commit
  log for lang/php52-pcre (or more than likely Attic'd lang/php5-pcre
  (again not a typo!)) would explain the justification.

I'm sure all this is one of many reasons ale@ is stressed out and why
PHP is such a son of a bitch.

All of my systems use lang/php5 (e.g. PHP 5.3.8), which is why I stated
what I did.  Hope this clears it up.  It's as simple as I could make it,
while providing insights.

Sorry for the confusion!

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |