This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __gmon_start__ symbol vs. dependencies between shared libraries
- From: Daniel Jacobowitz <drow at false dot org>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, ams at codesourcery dot com, kkojima at rr dot iij4u dot or dot jp
- Date: Tue, 1 Dec 2009 09:28:20 -0500
- Subject: Re: __gmon_start__ symbol vs. dependencies between shared libraries
- References: <87tywbt50k.fsf@dirichlet.schwinge.homeip.net>
On Tue, Dec 01, 2009 at 10:31:07AM +0100, Thomas Schwinge wrote:
> That is, __gmon_start__ is required for order2mod3.so, and is bound to
> order2mod1.so's (weak) definition. Correct would be that order2mod3.so
> falls back to its *own* (weak) definition of it, unless the real
> definition of this symbol is linked in through gcrt1.o.
>
> The following tiny patch fixes this, and makes the following tests pass,
> which failed previously: elf/reldep3.out, elf/neededtest.out,
> elf/order2.out.
I'm not sure this patch has the effect you wanted. If you have a
weak, hidden definition, will the linker ever call a strong version
if it's in a different DSO? I don't think so; .hidden will suppress a
dynamic relocation against the __gmon_start__ name.
SH seems to be the only architecture with a weak definition of
__gmon_start__. And it isn't doing anything, that I can see.
Should it be replaced with a conditional function call?
--
Daniel Jacobowitz
CodeSourcery