[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 20:03:29 +0100
On 2010-11-15 at 16:32:03 [+0100], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> 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.
Weak symbols are used for stuff where there must only be one definition
(respectively one that is used). The linker folds all weak definitions into
one. The runtime loader essentially does the same, just by resolving all
references to the same definition.
Symbol preemption is really only about overriding a symbol. When the linker
encounters two non-weak symbols to be linked into the same shared object, it
fails. It's also possible to prevent preemption of a certain symbol in a
shared library (by setting its visibility to protected), while the same
symbol in other shared objects could remain preemptable.
> > 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.
B_USE_DEFAULT_SPACING was introduced in r38512 (2010-09-03). If the
WebPositive sources haven't been adjusted afterwards (and weren't already
explicitely using a 0 spacing), the observed problem is indeed what one would
expect.
> If it would help, I can put a tarball of the source tree on
> the box you have ssh access to after work today.
Sure, thanks!
CU, Ingo
Other related posts:
