Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
To: dev@openoffice.apache.org
References: <003c01d17323$b021a6a0$1064f3e0$@acm.org>
 <56D72FF5.9090307@acm.org> <00ab01d174bb$a5d0dc90$f17295b0$@acm.org>
 <005c01d17580$ecab0670$c6011350$@acm.org> <56D8BCC3.4070008@acm.org>
 <00d801d175b1$4fff2f00$effd8d00$@acm.org> <56D8E840.8050205@acm.org>
 <CAJm2B-k1K34tmkRdiO+ZNXTuMLVGwrgsmSTX7hqKOZT-t=dZiQ@mail.gmail.com>
From: Patricia Shanahan <pats@acm.org>
Message-ID: <56D95C86.5010602@acm.org>
Date: Fri, 4 Mar 2016 01:59:34 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CAJm2B-k1K34tmkRdiO+ZNXTuMLVGwrgsmSTX7hqKOZT-t=dZiQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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