From owner-freebsd-apache@FreeBSD.ORG Wed Sep 21 12:03:15 2011 Return-Path: Delivered-To: freebsd-apache@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05AB6106566C for ; Wed, 21 Sep 2011 12:03:15 +0000 (UTC) (envelope-from ndhertbsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDFA58FC22 for ; Wed, 21 Sep 2011 12:03:14 +0000 (UTC) Received: by iadk27 with SMTP id k27so2661950iad.13 for ; Wed, 21 Sep 2011 05:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGprwbUSTAGGT6vEUO6sSkDw4umW9FZBb3l7irWkOi4=; b=sEN1wrVtGf4vs/h+yvmrSJBbw4uiB1zNyksJIibmloRY88wKpcwJv+ceoFSQhUZkeg scNaYYYIqqlfG8xVXYJO/T9g8z5cH1ZL83mck3yXUx90oM6REMxnwqLa/CR80jugHZh1 k8ut7PArH0DZTwZ2rX0h5QxCViJcC4kP2pg70= MIME-Version: 1.0 Received: by 10.231.9.1 with SMTP id j1mr1418238ibj.19.1316604883401; Wed, 21 Sep 2011 04:34:43 -0700 (PDT) Received: by 10.231.53.9 with HTTP; Wed, 21 Sep 2011 04:34:43 -0700 (PDT) In-Reply-To: <20110921095117.GA35011@icarus.home.lan> References: <4E78EF21.3010002@FreeBSD.org> <4E7974C5.20004@FreeBSD.org> <20110921054154.GA30759@icarus.home.lan> <4E7991D7.10004@gmx.de> <20110921082241.GA33410@icarus.home.lan> <20110921095117.GA35011@icarus.home.lan> Date: Wed, 21 Sep 2011 13:34:43 +0200 Message-ID: From: n dhert To: freebsd-apache@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: upgrade apache-2.2.20 -> 2.2.21 X-BeenThere: freebsd-apache@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Support of apache-related ports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 12:03:15 -0000 sorry, gmail default does not reply to Cc: forgot about that... I see I had the wrong specification in the config options of php52-pcre about the BUNDLED-PCRE for over a year ... it only agve errors now (there have been regular updates to php52=*, apache, pcre all over that year ... (I do portupgrades every week what pkg_version -vIL= asks me to do ..) so, nothing to do with apache... Thx 2011/9/21 Jeremy Chadwick > 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 > > > > > 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]: > - 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 | > >