[haiku-commits] Re: r39422 - haiku/branches/developer/bonefish/weak-symbols/build/jam
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 15 Nov 2010 16:10:49 +0100
On 2010-11-15 at 14:45:37 [+0100], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> On Sun, Nov 14, 2010 at 7:20 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > Well, symbol preemption is a bitch. Or actually it's a nice feature, but
> > enabling it after never having considered it is just bound to turn up
> > clashes. I already fixed a few instances, and a quick look at the now
> > crashing Icon-O-Matic seems to indicate another one. The WebPositive issue
> > most likely has the same root cause. I'll try and track it down tomorrow.
>
> One thing I'm not clear on: why does symbol preemption kick in at all
> in these cases? I thought you explicitly had to declare a symbol as
> weak with __attribute__ ((weak)) in order to allow it to be
> preemptible at all?
Symbol preemption is not directly related to weak symbols. It just means that
a symbol definition in a shared object can be overridden by a definition in
another shared object loaded earlier. Our runtime loader has been supporting
that for quite a while, but our gcc configurations basically disabled that
feature again (via -Bsymbolic). I'll write a more detailed explanation to the
development list soon, as we'll need to decide whether/when we want to merge
my branch into the trunk.
Anyway, since I can't check out the WebPositive sources ATM (trying to
connect svn times out (also under Linux)), I can't really look into it. It
doesn't seem to be related to symbol preemption, though. Disassembling the
URLInputGroup(BMessage*) constructor (BTW, there are two instances of it in
the executable) shows that the old executable passes a 0 spacing to the
BGroupView constructor, while the new executable passes 0xc0000000, which I
guess is B_USE_DEFAULT_SPACING. Assuming that the old executable was built
before the introduction of B_USE_DEFAULT_SPACING, I would say this is quite
expected and I would also expect an executable built under the current Haiku
trunk version to have the same issue. Did you perhaps build with the old
headers installed?
CU, Ingo
Other related posts:
