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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
