[haiku-commits] Re: r39422 - haiku/branches/developer/bonefish/weak-symbols/build/jam

On Mon, Nov 15, 2010 at 10:10 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> 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

Care to elaborate on the distinction then? I always thought the weak
attribute was intended to indicate precisely that a symbol was
eligible for that kind of preemption.

> 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?

Hm, I'm fairly sure that hasn't changed recently...will look into that
though. If it would help, I can put a tarball of the source tree on
the box you have ssh access to after work today.

Regards,

Rene

Other related posts: