upgrade apache-2.2.20 -> 2.2.21
n dhert
ndhertbsd at gmail.com
Wed Sep 21 12:03:15 UTC 2011
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 <freebsd at jdc.parodius.com>
> 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 at 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 |
>
>
More information about the freebsd-apache
mailing list