openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Date Fri, 04 Mar 2016 09:59:34 GMT
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message