Seems it was the way i configured libxml2? this was my setting

./configure --prefix=/Apache/local/libxml \
--enable-shared \
--with-zlib=/Apache/local/zlib

do you see how it would generate that error? is this zlib directory the same as the one configured in php? 

I was able to use a binary version of libxml2 when i configured php to successfully build.

Check that your installed libxml2 is clean, ie. you don't have messed up the headers vs. libraries when installing it. It happens when if you install it from sources and don't remove the existing installation first. Most likely this is just a messed up installation of libxml2 so the easiest way to solve it is first removing all instances of any libxml2 related files from your system and reinstalling it from scratch, then do the same for PHP. (use _fresh_ sources!)

I also have this same problem on Leopard.
But solution which you wrote, "remove all instances of libxml from your system" can only crash Leopard ( http://jamesclarke.info/notes/libxml2/ - see comments ).

My "sudo make" also return this same error like in danval situation.

Compiling libxml2 from source solved this for me

The problem is described here:

http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-
compiling-php-528/

The provided solution (editing Makefile) worked for me.

Tried recompiling PHP again some time after doing it with the fresh libxml2 install, and it no longer works, breaking with the same error as above.

Also tried the Makefile editing and it still gives me tehe same errors.
Tried with PHP 5.3.0RC2 and HEAD

Ok.

Phillips solution points to the right direction. The changes in the Makefile did not work for me, seems there was more then one point to it.

The solution came down to adding -L/path/to/lib in front of all the commands that generate the broken message reported above.

I then ran these commands (2 in my case, for libphp5.so and the cli) by hand and ran make again, so it pickedup from where it had stopped.

This worked for me in 5.3RC2 and HEAD. 

PS: you need to include "lib"in the --with-libxml-dir and in these paths above

Does it work, if you write

--enable-xmlreader=/Apache/local/libxml

in your ./configure call?

It works for me at least ...

@chregu

My ./configure had that and it pointed to /opt/xml/lib .. this only stopped the error for the CLI compile.. not the libphp5.so command. On that one i still had to add the -L directive stated above

actualy sorry.

I had --with-libxml-dir declared.
Tried running it with --enable-xmlreader-/opt/xml/lib, just like the above setting and it broke on the same place as before.

Remove the /lib from those paths. "rdohms at gmail dot com":  Where did 
you get the idea it's okay to pass that anywhere?!

And if you change the version, add a note about it. Now there's no way 
to know what version you reported this with, what version it works 
with..etc.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Jani.

Adding /lib was the only way i got it working.. otherwise it skipped those dirs and kep hamerring /usr/lib which is the next in line, like here:

cc -bundle -bundle_loader /Applications/Server/Apache2/bin/httpd  -L/usr/lib -L/usr/lib -laprutil-1...

What i have been doing to compile succesfully is altering to this

cc -bundle -bundle_loader /Applications/Server/Apache2/bin/httpd -L/opt/xml/lib -L/opt/local/lib -L/usr/lib -L/usr/lib -laprutil-1...

This was gwyne's suggestion and it works great.

After I enabled OpenSSL i got evem more of these, hence the /opt/local/lib i also placed there.

As for versions, i have reproduced these today on:
PHP_5_3, PHP_5_2 and trunk, straight from SVN


I'm rdohms on php.pecl if you want to chat about this

Issue still exists in 5.x trunk from SVN.

The solution is simple: in the Makefile, on the line where "libs/libphp$(PHP_MAJOR_VERSION).bundle:" appears, the $(MH_BUNDLE_FLAGS) variable should be called after "$(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS)" so that the hard-coded "/usr/lib" search path is searched after any user-provided search paths given during configure.

For example, the Makefile currently contains this passage:

"MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/sbin/httpd -L/usr/lib -L/usr/lib -laprutil-1 -lsqlite3 -lexpat -liconv -L/usr/lib -lapr-1 -lpthread"

...which sets library search paths as '/usr/lib'.

Further below:

"libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
        $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so"

...demonstrates that the '-L/usr/lib' from $MH_BUNDLE_FLAGS is given priority and will be searched before the '-L/custom/paths' contained in the variables immediately following it. This is likely not the intended behaviour, since it circumvents the user's intentions when passing library search paths to the configure script.

What should be found in the Makefile—which will resolve this issue—is the following:

"libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
        $(CC) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(MH_BUNDLE_FLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so"

Can anyone with autotools and PHP build process familiarity comment on any possible repercussions from this minor and logical change?