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
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
