Date: Wed, 21 Sep 2011 01:22:41 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: olli hauer <ohauer@gmx.de> Cc: n dhert <ndhertbsd@gmail.com>, apache@FreeBSD.org Subject: Re: upgrade apache-2.2.20 -> 2.2.21 Message-ID: <20110921082241.GA33410@icarus.home.lan> In-Reply-To: <4E7991D7.10004@gmx.de> References: <CAEFCw4tB8Db1ab=Sj20fktVxqsUjBzMt2dw9jxqYtKoiOgXKgQ@mail.gmail.com> <4E78EF21.3010002@FreeBSD.org> <CAEFCw4tD=8v8qyBiYs49xEFARART_WqVDPPQsj4vH9LnXnTESw@mail.gmail.com> <4E7974C5.20004@FreeBSD.org> <20110921054154.GA30759@icarus.home.lan> <4E7991D7.10004@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110921082241.GA33410>