I'm having trouble installing the DBG module into my apache server, when it starts up I get this in the error log:

[30-Jul-2006 11:15:11] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/dbg.so-5.1.x' - /usr/local/lib/php/dbg.so-5.1.x: undefined symbol: OnUpdateLong in Unknown on line 0

I'm running PHP 5.1.4 and Apache 2.0.55 on Redhad Linux Enterprise 4

Any idea whats up?

OnUpdateLong is an export symbol of PHP core (main.c) and must be there.
Check if you have a) a properly created php binary or shared library. I'd highly recommend you not to strip symbols. b) check if you are trying to install module intended for your platform (for example x86 vs x86_64).

Here's my configure string, don't see any stripping. I'm using the correct binary, x86 on an x86 build of Linux Enterprise 4

./configure --with-apxs2=/usr/sbin/apxs --with-xml --enable-bcmath --enable-calendar --with-curl --enable-ftp --with-gd --with-jpeg-dir=/usr/local --with-png-dir=/usr --with-xpm-dir=/usr/X11R6 --enable-magic-quotes --with-mysql=/usr --with-openssl --enable-discard-path --with-pear --enable-sockets --enable-track-vars --with-ttf --with-freetype-dir=/usr --enable-gd-native-ttf --enable-versioning --with-zlib --with-config-file-path=/etc --with-kerberos --with-mime-magic --enable-mbstring --with-mysqli --enable-pcntl

Stripping may happen as a final stage during make.
Also, please check that php is really of version 5.1.4
If it is say 4.4.2, it does not have OnUpdateLog and may get you exactly what you're experiencing.

phpinfo() reports 5.1.4. How can I tell if gmake is stripping? Is there a way I can prevent it from doing so?

try
nm libphp5.so
to see if symbols are stripped or not.

For example libphp4.so has OnUpdateInt and therefore:
$ nm libphp4.so |grep OnUpdateInt
shows:
001394a8 T OnUpdateInt

if you get anything like this
$nm libphp5.so
nm: libphp5.so: no symbols
it means that the symbols are stripped off and this module can not use php extensions compiled as shared objects.

check both, libphp5.so produced in php source directory and installed for apache.

FYI gmake or make itself does not do anything on the binaries, it must be happening due to a rule in Makefile or in a file it includes or in the script that performs install.

Okay, gotten a bit further. The libphp5.so it was referencing in the LoadModule line had the symbols, I found another version of the libphp5.so module which didn't expose any symbols (which shouldn't have been loading, but apparently was) and removed it.

Now I'm getting a slightly different error on startup, I get:

[31-Jul-2006 09:52:16] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/dbg.so-5.1.x' - /usr/local/lib/php/dbg.so-5.1.x: undefined symbol: compiler_globals in Unknown on line 0

Here's the output on nm:

nm libphp5.so | grep compiler_globals
00267d50 t compiler_globals_ctor
00267ed8 t compiler_globals_dtor
0051e8a4 b compiler_globals_id

It looks like you are trying to build php binaries with TSRM (thread management) enabled.
It neither works nor supported under Linux. TSRM itself is an experimented feature and is useful under Windows only.

Compile without thread manager and it will work (with apache pre-fork of course).

Ahh, thats the problem, I'm using worker.c with apache. I belive Zend's debugger had this limitation as well, can you tell me your debugger can't use threads?

Thanks

It is not a limitation of the debugger and for example under Windows it does use threads. Nothing prevents from compiling it with TSRM under Linux as well.
The problem lies deeper. Most if not all php extensions are really wrappers around 3rd party libraries which are known to be NOT threadsafe.
For example you are compiling Curl, GD and FreeType. Are you sure they are threadsafe?

I see. No I'm not certain that they are threadsafe, I'll consider switching back. I just thought that worker.c had signification performance enhancements over pre-fork.

Right prefork is somewhat slower and has quite bigger memory footprint. But it does not make big sense because there are threadunsafe libraries used by php extensions.
Let's take more reliable way. Meanwhile people are working on their libraries in order to make them threadsafer. Perhaps, one day we'll see it all working fast and reliable simultaneously.