On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <p...@acm.org> wrote: > On 3/4/2016 12:54 AM, Damjan Jovanovic wrote: >> >> ELF binaries (Linux, *BSD) fundamentally use one of the worst ideas of >> all time: symbols are process scoped (unlike on Windows and MacOS >> where they're library scoped), meaning that symbols with the same name >> can clash even if in different libraries loaded through arbitrary >> layers of indirection. For example, compiling AOO with GCC on recent >> FreeBSD easily crashes AOO because both GCC's and Clang's C++ runtime >> libraries are loaded, their symbols clash with each other, and their >> ABIs are not fully compatible -> memory corruption -> undebuggable >> crash. Symbol map files are supposed to work around the problem >> because the UDK_3_0_0 becomes part of the symbol name and makes it >> more globally unique. >> >> I don't know if UDK_3_0_0 is correct since we are on AOO version 4 now >> (or do we version UDK differently?). > > > Embedding version numbers in source code should be done very sparingly, > because it grows old fast. > >> >> Also UNO is all good in theory, but in practice plugins can always use >> run-time dynamic linking to load any library and call any exported >> function (which the profile functions are) - even when running in a >> separate process, or written a different language (eg. JNA/BridJ for >> Java). Whether they actually do this in practice is the more important >> question. > > > I have a possibly pathetic hope that the 14 year deprecation of the > functions may have discouraged their direct use in plugins. > >
main/sal/rtl/source/bootstrap.cxx uses osl::Profile().readString() in 1 place. osl::Profile found in main/sal/inc/osl/profile.hxx is a thin C++ wrapper around the C API. That seems to be the extent of the usage of the profile API in SVN trunk. I can't remember where else I found them, but on https://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Manual_Component_Installation there is a brief mention of these ini/rc files that I suspect are parsed by the profile API. Examples are in the program/ directory of the AOO installation (there is quite a few, all ending in ".ini" on Windows and "rc" elsewhere, eg. uno.ini/unorc). As for locking, all platforms can and do lock the file against access from other processes (LockFileEx on Windows, fcntl+F_SETLKW on *nix) though on *nix it is only *advisory* locking. The pthread API would only be useful to ensure thread safety within the process. I presume "bootstrapping" only happens once per process, so it can't really be multi threaded anyway? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
