Stephan Bergmann wrote: >>> On 04/28/09 14:27, Thorsten Behrens wrote: >>>> well, Win32 is only one platform, and experience tells that in >>>> general, c++ extension *do* break between releases. But you're >>>> right, that's not necessarily caused by ABI changes in the strict >>>> meaning of the word, a case in point is the 3 layer OOo rework. >>> Hu? >>> >> http://www.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=24706 >> and >> http://www.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=24718 >> for example. > > Maybe I am dumb, but I do not find any mention of broken C++ OOo > extensions in those two mails. > Hi Stephan,
oh, I was under the impression the author is referring to c++ - so then, it's Java? Should we add Java to the list of fragile extension implementations as well? ;) >> And of course with symbol interposing on elf-based platforms, you >> get all the fun if someone injects names into the OOo process that >> are normally bound to e.g. another version of a shipped external >> lib... > > I do not see how that would relate to the topic of this thread. > Sorry for not being clear - symbol interposing makes it even harder to maintain compatibility for c++ extensions, due to the mutual influence the OOo baseline & extensions have on symbol resolution (i.e. a dso already in the lookup scope when an extension is loaded can mess with the extension; conversely, with OOo dlopening uno components using RTLD_GLOBAL, the extension's dependencies can mess with OOo). Although I'd think symbol versioning is supposed to solve this problem, there are apparently enough corner cases (or badly-versioned libs) out there that it fails: http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=23388 (I also remember problems with different versions of the freetype lib, but cannot find any reference currently) Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
