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.

Patricia



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to