Hello All, I looked into the way expat is built and used in AOO.
TL;DR: expat functions are partially taken from our expat, and partially from system-level expat. On Sun, Oct 12, 2025 at 09:31:57AM +0200, Arrigo Marchiori wrote: > Hello All, > > On Sat, Oct 11, 2025 at 05:52:08PM +0000, Damjan Jovanovic wrote: > > > This seems like a problem with fontconfig's use of expat? According to the official build scripts, our own version of expat is built in the main/expat module, and then it is _statically_ linked where it is necessary. Fontconfig, on the other hand, is accessed as a shared library. Fontconfig needs expat. It is linked to it dynamically, at least on openSUSE, and that would make sense everywhere IMHO. I had gdb break on function XML_ParserCreate(), that is one of the expat initializator functions. It is first called by fontconfig, when our vcl module initializes it. gdb breaks on the implementation of XML_ParserCreate() in /usr/lib64/libexpat.so, that is the system-level expat dynamic library. As explained above, this makes sense, because it's being called by fontconfig, that is another system-level dynamic library. Function XML_ParserCreate() is very simple: it just calls XML_ParserCreate_MM(), that is another function defined in the same file of the expat source code. The problem is that, on my system, this function XML_ParserCreate_MM(), called from the system-level dynamic library, is not taken from the same system-level dynamic library /usr/lib64/libexpat.so, but rather from AOO's openoffice4/program/libhelplinker.so That is: an implementation from our own statically linked expat. In other words, we are mixing pieces of the system-level expat, with pieces of our own version of expat, that are taken from one of our .so libraries, where they are statically linked. This explains why the configure script parameter --with-system-expat solves the crash: all references to expat from AOO and fontconfig point to the same, system-level dynamic library. There is only one expat library and no conflicts or mix-ups are possible. The real crash is due to an unitialized parameter in the "parser" structure that is constructed by function XML_ParserCreate(). I think that the details are not important: the important issue is that the two expat implementations are being confused and mixed with each other. Why is the system-level libexpat.so calling internal functions of our own statically linked expat? How can we avoid it? Thank you in advance and best regards, -- Arrigo --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
