Le Lundi 13 Juin 2005 11:33, Thomas Jarosch a écrit : > On Monday 13 June 2005 11:16, Christophe de VIENNE wrote: > > Le Lundi 13 Juin 2005 10:39, Thomas Jarosch a écrit : > > > > Can you be more precise ? What is broken exactly ? > > > > It the php xml parser is base on libxml2 and use it's callback (as we > > > > do with libxml++), then I don't think a cohexistence is possible. > > > > > > PHP uses libxml2 without those callbacks. As soon as I create a node > > > using PHP function calls, I end up in libxml++'s callback :o) > > > > Wait, is the problem the callbacks themselves ? Are they disturbing the > > php xml parser ? the thing is that libxml++ cannot work properly without > > them. > > Exactly! The root of the problems seems to be that libxml++ and PHP > both manipulate the node->_private pointer for their own needs. Now it's clearer :-) > > > The problem with the "static" class is that it gets executed > > > during library load time. This is why it breaks PHP. > > > > Do you need it not to be executed at all, or only once ? > > Only init once and reset after libxm++ code usage. > Something like: > > - libxml::init() > - XML manipultions via libxml++ > - libxml::deinit() Well, to do libxml::init() and libxml::deinit(), you can simply control a Document::Init instance. The thing is that you need it not to be default initiated. Globally, this solution looks heavy to me, but I don't see a workaround. So it looks like a --disable-static-initialisation in the configure script would solve the issue. Any objection ? Christophe
Attachment:
pgpuIRezwUddR.pgp
Description: PGP signature