OK, heres another clash:
(gdb) bt
#0 0x28691f16 in GetToken () from /usr/local/lib/libMagick.so.7
#1 0x299c6198 in ParseDocument () from /usr/local/lib/libtidy-0.99.so.0
#2 0x299e1362 in tidyDocParseStream () from
/usr/local/lib/libtidy-0.99.so.0
#3 0x299e0cbb in tidyDocParseString () from
/usr/local/lib/libtidy-0.99.so.0
#4 0x299e09c4 in tidyParseString () from /usr/local/lib/libtidy-0.99.so.0
#5 0x299a4b61 in zif_tidy_parse_string () from
/usr/local/lib/php/20041030/tidy.so
#6 0x08161db3 in zend_do_fcall_common_helper ()
#7 0x0816210e in zend_do_fcall_handler ()
#8 0x0814fe7e in execute ()
#9 0x08128064 in zend_execute_scripts ()
#10 0x080e8411 in php_execute_script ()
#11 0x00000000 in ?? ()
#12 0x00000003 in ?? ()
#13 0x00000000 in ?? ()
#14 0xbfbfe7b4 in ?? ()
#15 0x00000000 in ?? ()
#16 0x00000002 in ?? ()
#17 0x284d976c in ?? () from /lib/libc.so.6
#18 0x0828d700 in ?? ()
#19 0x00000080 in ?? ()
#20 0x0828d780 in ?? ()
#21 0x0812f5cd in _zend_hash_add_or_update ()
#22 0xbfbfe3d0 in ?? ()
#23 0x00000080 in ?? ()
#24 0x28467e4f in _UTF8_wcsnrtombs () from /lib/libc.so.6
Previous frame inner to this frame (corrupt stack?)
Disabling ImageMagick allows Tidy to work properly.
I really think that rather than sitting around pointing fingers at the
developers of the libraries (and yes, I understand that they really should
be decorating all exported symbols), the PHP team should take steps to
prevent these problems from happening by not loading all third party
libraries (I count over 30 on my installation) into the same namespace.
I still think that dlopen() and friends is the best way to tackle this on
platforms that support it - does anybody know of any PHP supported platforms
that don't support dlopen()? Other than the effort of converting the current
extensions (or at least, the ones with known clashes), is there any reason
not to try and work around these problems?
--
Alastair D'Silva mob: 0413 485 733
Networking Consultant fax: 0413 181 661
New Millennium Networking web: http://www.newmillennium.net.au