> that sw can call it? don't we use default hidden visibility on Mac > platform?
Don't think so. At least in that Mac build tree I have that uses Xcode 3 and its gcc 4.0.1 and the 10.4 SDK, config_host.mk ends up with HAVE_GCC_VISIBILITY_FEATURE blank. On the other hand, solenv/gbuild/platform/macosx.mk unconditionally sets gb_COMPILERDEFS += -DHAVE_GCC_VISIBILITY_FEATURE ? Weird. Either visibility is something that really works "as expected" only with gcc and ELF (because, I guess, that is what those who expect it to work use;), or then the configure.in fails to recognize it working well enough. Is visibility, as we want it, something that also the object and/or dynamic library format(s) need to support, or can it be implemented just in a compiler? Note that Xcode 3 and the 10.4 SDK are obsolete but we keep requiring them as the official build environment because we want to keep producing binaries that work on 10.4. It is possible now, though, to build LO master also using a current (4.3.x) Xcode, and its Clang even, against the 10.6 SDK, but it has not been tested really that much. I now remember that I had to add a few lines to disable HAVE_GCC_VISIBILITY_FEATURE in configure.in when using Clang for MacOSX, because of some weird linking errors in connectivity and dbaccess. But maybe if the root cause to chose could be resolved, visiility could be used in that build configuration, at least? --tml _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice