PHP warning after 5.3.3 -> 5.3.3_1 bump

Jeremy Chadwick freebsd at
Thu Aug 26 13:35:33 UTC 2010

On Thu, Aug 26, 2010 at 08:41:42AM -0400, Greg Larkin wrote:
> Morgan Wesström wrote:
> > Upgraded lang/php from port revision 5.3.3 to 5.3.3_1 yesterday to
> > include the new native MySQL drivers. Now I get the following warning
> > every time a php script is executed:
> > 
> > PHP Warning:  Module 'zlib' already loaded in Unknown on line 0
> > 
> > Even a simple "php -v" displays this warning.
> > 
> > - I have rebuilt php and all ports depending on it.
> > - I have verified that extensions.ini doesn't contain duplicates.
> > - I have searched for any other references to zlib.
> > 
> > This isn't critical I guess, but annoying. Any suggestions on how to
> > solve this would be appreciated.
> > 
> > Regards
> > Morgan
> Hi Morgan,
> The only time that I've seen that error, it has been caused by duplicate
> extension loading.  If you've already removed duplicates from your
> extensions.ini file, set up a page with the phpinfo() function so you
> can see what other .ini file directories might be in the search path.
> You might even get some good information from this command:
> truss -f -a -s 256 -o /tmp/php-cli.log php -v
> Once the process exits, check the /tmp/php-cli.log file and search for
> "zlib" in it.  You might see the zlib extension loaded more than once
> and be able to determine what .ini file is causing the duplication.

I should note there were zlib-like changes made within Makefile.ext
during the commit.  Let me explain what I mean by that, because there
weren't any *actual changes* to the zlib extension itself:;r2=1.75;f=h

The change here introduces --with-zlib-dir to the configure arguments in
the case that the standard MySQL extension ( or
PDO-based MySQL extension ( is used.

Please note the below is speculative on my part, but it wouldn't
surprise me if it turned out to be the case.

I wonder if the introduction of this configure variable causes PHP to
automatically load the zlib extension on its own (think: PHP extension

If this is true, then would be considered "redundant"
and cause the warning seen.  You could test the validity of my claim by
commenting out (using semi-colon) in extensions.ini
and then use php -i and see if zlib is listed as a loaded extension.

Solving this, if true, is tricky.  The only solution I can think of
would be to remove the archivers/php5-zlib port altogether, and instead
make lang/php5 include zlib support natively.  FreeBSD's libz is quite
small, so memory usage per PHP instance would not skyrocket assuming
libz is included as a shared library (I hope PHP supports that vs.
including it statically).

Food for thought -- and as such, I'm CC'ing ale@ to partake in the

| Jeremy Chadwick                                   jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

More information about the freebsd-ports mailing list