On Mar 9, 2007, at 13:59, Tom Brice wrote:

I am seeing the same thing on a machine running OS X 10.3.9. I have installed sqlite3 from MacPorts (sqlite3 is not included with OS X 10.3.9). Here is what I did on a new (empty) install of MacPorts:

$ sudo port install sqlite3 $ sudo port isntall libiconv +darwin_7 $ sudo port install apache2 +darwin_7

FYI: The darwin_7 variant is auto-selected on Mac OS X 10.3.x; you do not need to specify it yourself. Also, the apache2 port depends on the apr-util port, which depends on the libiconv port, so you don't need to install libiconv yourself. MacPorts is here to handle all this for you.

at this point I verified that Apache was functional. No errors on startup and served pages as expected.

$ sudo port install php5 +apache2 +darwin_7 +pear +mysql5

After this completed with no errors I get in error_log when trying to start apache (/opt/local/apache2/bin/apachectl start):

dyld: /opt/local/apache2/bin/httpd Undefined symbols: _sqlite3_bind_parameter_count _sqlite3_bind_text _sqlite3_changes _sqlite3_close _sqlite3_column_bytes _sqlite3_column_count _sqlite3_column_name _sqlite3_column_text _sqlite3_column_type _sqlite3_errmsg _sqlite3_finalize _sqlite3_free _sqlite3_mprintf _sqlite3_open _sqlite3_prepare _sqlite3_reset _sqlite3_step

Same a original post. Perhaps there is an option that should be included in configure for darwin 7 that points to a MacPorts install of sqlite3? Any other ideas?

MacPorts philosophy is to not use the system's version of a software package unless absolutely necessary. See the FAQ on the web site. Therefore if software requires sqlite3 it should use the MacPorts version of sqlite3, not the system's version. I see with "otool -L /opt/local/apache2/bin/httpd" that on my 10.4.8 PPC system it depends on /usr/lib/libsqlite3.0.dylib. So the apache2 port should be modified to depend on the sqlite3 port and to use that version of sqlite3 instead. In the original thread on this topic to which you refer, I thought php5 was causing the problem. But "otool -L /opt/local/bin/php" and "otool -L /opt/local/apache2/modules/libphp5.so" make no mention of a dependency on sqlite3 so I'm now inclined to think it's the apache2 port that needs to be changed, not the php5 port. I'm CCing the apache2 port maintainer on this.

MacPorts philosophy is to not use the system's version of a software package unless absolutely necessary. See the FAQ on the web site. Therefore if software requires sqlite3 it should use the MacPorts version of sqlite3, not the system's version.

I see with "otool -L /opt/local/apache2/bin/httpd" that on my 10.4.8 PPC system it depends on /usr/lib/libsqlite3.0.dylib. So the apache2 port should be modified to depend on the sqlite3 port and to use that version of sqlite3 instead.

In the original thread on this topic to which you refer, I thought php5 was causing the problem. But "otool -L /opt/local/bin/php" and "otool -L /opt/local/apache2/modules/libphp5.so" make no mention of a dependency on sqlite3 so I'm now inclined to think it's the apache2 port that needs to be changed, not the php5 port.

I'm CCing the apache2 port maintainer on this.

As another datapoint, I got bit with this last night after rebooting a 10.3.9 server after applying the security update. My apache2 was (and is) linked against the MacPorts sqlite: /opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) and none of the php libraries seemed to be. Nevertheless, apache would not run until I commented out the AddModule for php and php include. I rebuilt the whole dependency tree several times and I'm fairly certain its not an issue due to libsqlite being updated or any such thing. The missing symbols exist in the libsqlite.dylib if I dump it with nm, so it seems that the php module is throwing off the dynamic linker somehow at runtime. I wasn't using php for anything any more so I just disabled it, I was unable to find a fix. Thanks, ERic

On Mar 14, 2007, at 9:59 PM, Eric Cronin wrote:

...

MacPorts philosophy is to not use the system's version of a software package unless absolutely necessary. See the FAQ on the web site. Therefore if software requires sqlite3 it should use the MacPorts version of sqlite3, not the system's version.

I see with "otool -L /opt/local/apache2/bin/httpd" that on my 10.4.8 PPC system it depends on /usr/lib/libsqlite3.0.dylib. So the apache2 port should be modified to depend on the sqlite3 port and to use that version of sqlite3 instead.

In the original thread on this topic to which you refer, I thought php5 was causing the problem. But "otool -L /opt/local/bin/php" and "otool -L /opt/local/apache2/modules/libphp5.so" make no mention of a dependency on sqlite3 so I'm now inclined to think it's the apache2 port that needs to be changed, not the php5 port.

I'm CCing the apache2 port maintainer on this.

As another datapoint, I got bit with this last night after rebooting a 10.3.9 server after applying the security update. My apache2 was (and is) linked against the MacPorts sqlite:

/opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)

and none of the php libraries seemed to be. Nevertheless, apache would not run until I commented out the AddModule for php and php include. I rebuilt the whole dependency tree several times and I'm fairly certain its not an issue due to libsqlite being updated or any such thing. The missing symbols exist in the libsqlite.dylib if I dump it with nm, so it seems that the php module is throwing off the dynamic linker somehow at runtime. I wasn't using php for anything any more so I just disabled it, I was unable to find a fix.

Thanks, ERic

I had a chance to come back to this today. I updated the MacPorts 1.4.0 and selfupdate/synced then reinstalled everything from scratch. Unfortunately I had the same results as before, apache2 working without mod_php... no joy with php5/apache2. I too have apache2 linked to the proper macports sqlite3 (as above) but this as well: # otool -L /opt/local/apache2/modules/libphp5.so /opt/local/apache2/modules/libphp5.so: ... /opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) ... After a little reading I see that PHP5 comes with sqlite3. The only conclusion that I can come to is that something is linking to the supplied sqlite3 rather than MacPorts version and the supplied sqlite3 fails on OS X 10.3.9 for some reason. Here's how I came to this end: * The php5 install that I cannot get to work with apache2 via mod_php does work in the CLI. * In the darwin 7 variant of the php5 Portfile I added "--with-pdo- sqlite=${prefix}/bin/sqlite3" to the configure.args-append line. Building this still fails mod_php usage with apache2. * I changed the darwin 7 variant to "configure.args-append -- without-sqlite --without-pdo-sqlite" and reintsalled. THIS WORKS with mod_php and apache2!! I wasn't using sqlite3 with php before so I can live without it. However, I think it might be "fixable" by making sure that php uses the MacPorts sqlite3 rather that the supplied version. By adding the appropriate DIR to "--with-sqlite=DIR --with-pdo-sqlite=DIR" it might work. I guess it should be "{prefix}/bin/sqlite3". the configure file states: "Use --with-sqlite=DIR to specify DIR where Sqlite include and library files are located, if not using bundled library." I'm not sure what the correct path for include and library files might be. Or I might be cracked. Anyway, I'm just happy to have php5 working on this Panther box. Now I can migrate some internal tools and subversion repos to this box. Tom

On Mar 31, 2007, at 5:28 AM, Ryan Schmidt wrote:

I have committed a new revision of the php5 port which disables standard and pdo sqlite support, and adds a new +sqlite variant for those who want to reenable it:

http://trac.macosforge.org/projects/macports/changeset/23410

This seems to work for me on 10.4.9 Intel. Will someone with access to 10.3.9 PPC please test it there and let me know if both versions work properly (both when specifying +sqlite and when not)? Thanks.

Thanks for looking into this Ryan. I just installed php5 on OS X 10.3.9 PPC using the new Portfile. Works fine without as well as with +sqlite. Woohoo! I'm pretty excited! Thanks for your patience. It's interesting to note that now PDO Driver for SQLite 3.x reports that it is using SQLite Library 3.3.13 (my Macports install) and SQLite support reports that it is using SQLite Library 2.8.17 (from the php5 source, I do not have sqlite2 installed via Macports). Perfect. Just as it should be! I have not checked that sqlite actually functions in a php script. When I get a chance to do so I will report back (just to be complete). Thanks again, Tom

On Mar 31, 2007, at 15:57, John Korchok wrote:

When I try: port install php5 +apache2 +mysql5 +fastcgi

I get: Error: Variant apache2 conflicts with fastcgi

Previously I thought this just meant that FastCGI was not written for Apache 2 yet, but it seems that it is. What does this message mean?

Thanks for any and all help.

It means that I need to get off my @$$ and make it possible to install both the apache2 module and the fastcgi binary at the same time. The php5 configure script makes it a little difficult. But I will do it soon, because I need it myself. However, to explain what the variants do: +apache2 installs the php5 apache module for apache2 (/opt/local/ apache2/modules/libphp5.so). If you want to use php5 from apache2 as an apache module, then this is the variant you want. This is the way that most people will want to use php5 within apache2. If you don't know whether you should use fastcgi or the apache module, go for the apache module. +fastcgi builds the php binary with fastcgi support (/opt/local/bin/ php-fcgi). If you want to use php5 from a fastcgi-capable web server, then this is the variant you want. lighttpd is one such web server. apache and apache2 also support the fastcgi interface, and if you only want to use php5 from apache or apache2 through the fastcgi interface (and not through the apache module interface), then you do not need (and should not use) the +apache or +apache2 variants, and should only use the +fastcgi variant. You will need to configure the fastcgi stuff yourself; the php5 port makes no attempt to do so for you, nor does it print instructions on how to do so, because frankly I don't know how to configure apache in that way. The reason I personally would like to use both +apache2 and +fastcgi is that I would like to have the php5 apache2 module for apache2, and the php5 fastcgi support for lighttpd. Yes, I have both apache2 and lighttpd installed and running simultaneously, each for different purposes.