Date: Wed, 21 Sep 2011 02:51:17 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: n dhert <ndhertbsd@gmail.com> Cc: freebsd-apache@FreeBSD.org Subject: Re: upgrade apache-2.2.20 -> 2.2.21 Message-ID: <20110921095117.GA35011@icarus.home.lan> In-Reply-To: <CAEFCw4skkm0NAasrkzxZm2Kn8xyL5rxoNxQ66yOitN=cNL8Vdw@mail.gmail.com> 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> <20110921082241.GA33410@icarus.home.lan> <CAEFCw4skkm0NAasrkzxZm2Kn8xyL5rxoNxQ66yOitN=cNL8Vdw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 21, 2011 at 10:58:10AM +0200, n dhert wrote:
> I see,on Aug 30, along with php 5.2,17_1 beging upgrade to _2
> also pcre-8.12 (perl compatible Regular expression library) was upgraded to
> 8.13_1 (not a minor upgrade)
> Could the problem be with the pcre package?
> or with php52-pcre?
>
> I have
> $ cd /usr/ports/devel/php52-pcre
> $ make showconfig
> ===> The following configuration options are available for
> php52-pcre-5.2.17_2:
> BUNDLED_PCRE=on "Select if you use apache 2.0.x"
> ===> Use 'make config' to modify these settings
> Should I
> # make config
> and uncheck the option (now checked)
> # make install clean
>
> ??
> 2011/9/21 Jeremy Chadwick <freebsd@jdc.parodius.com>
>
> > 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!
First and foremost:
When participating in a mailing list, please do not mail people directly
if you can avoid it. You've done this with Olli, and now you're doing
it with me, and you've also removed the CC list on your mail to me.
This is rude behaviour; please don't do this.
As for the issue:
Your problem is a little difficult to understand. Since you mailed
folks directly I don't have full context of your situation, though Olli
was kind enough to provide summarised version. Here's how I understand
it:
You upgraded your ports from Apache 2.2.20 to Apache 2.2.21, as well as
pcre 8.12 to 8.13, then began receiving these errors in your Apache
error log, generated from Drupal (which is PHP-based software):
warning: preg_match()
[function.preg-match<http://win.ua.ac.be/function.preg-match>]:
- Tekst uit oorspronkelijke bericht niet weergeven -
Compilation failed: internal error: previously-checked referenced
subpattern not found at offset 389 in
/usr/local/www/apache22/data/drupal-6.22/includes/database.inc on line
347.
These errors are generated from PHP. Apache-level errors are not shown
like this. I can tell just from the formatting of the errors that they
come from PHP/Drupal.
I believe what has happened is this, but please correct me if I'm wrong:
You somehow managed to upgrade your pcre library on the system without
rebuilding PHP.
In this situation, you are almost certainly going to experience internal
errors within any software that still has internal references to the old
pcre (8.12). The API or ABI semantics have very likely changed between
pcre 8.12 and 8.13. The end result is all sorts of internal failures
within whatever software is linked to/using pcre. Situations like this
usually warrant a library version number upgrade (e.g. libpcre.so.N to
libpcre.so.N+1), but that is up to the authors of the library, not
FreeBSD.
I'm inclined to believe you either ignored warning messages during the
pkg_delete ("make deinstall") phase of pcre's removal (you should have
received a warning telling you how other ports were dependent upon this
software), or if the deinstall did not work you used -f to force the
removal anyway.
This would only affect someone using lang/php52 (not lang/php5 -- see my
previous Email for why lang/php5 (PHP 5.3.8) would not be affected).
To solve this, you will need to do two things:
1) pkg_delete all PHP ports on the system. You will be responsible for
making sure there is nothing "left over" in /usr/local from this, or
if Drupal or other software on the machine has installed things in
places where the PHP ports are
2) rm -fr /var/db/ports/php52-pcre -- this will ensure that any previous
setting you chose for the BUNDLED_PCRE option will get reset. Since
you're using Apache 2.2.x, you *DO NOT* need to enable this OPTION.
Leave the checkbox unchecked.
3) Rebuild + reinstall all previously-deleted PHP ports.
You should do this every single time you wish to upgrade any library
which PHP relies on. Yes, you read that correctly.
You should not need to rebuild Apache.
I want to make this extra, crystal clear, because many people think they
can outsmart the system:
DO NOT JUST REBUILD PHP52-PCRE. Play it safe: rebuild *ALL* of your PHP
ports. PHP is well-known for behaving very oddly if you "mix-match"
versions or builds, especially when 3rd-party libraries (PCRE) are
involved. I have a customer who did this a year or so ago, and had the
chutzpah to ask me what *I* had done to the system to cause problems
with some of his PHP software.
--
| 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?20110921095117.GA35011>