This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: About hacking libc
- From: Nix <nix at esperi dot org dot uk>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Xinyang Ge <xxg113 at cse dot psu dot edu>, "Carlos O'Donell" <carlos at systemhalted dot org>, libc-help at sourceware dot org
- Date: Wed, 24 Apr 2013 22:39:47 +0100
- Subject: Re: About hacking libc
- References: <CACY857JO7HoMRQyX1sb1gqR0DzK0PksBy0OPd7awCVbBSVKCPQ at mail dot gmail dot com> <CAE2sS1hv8CU45snKVOSzqYv-J9f4GcVp6v8GyAEg93cSQ=NWow at mail dot gmail dot com> <CACY857+73GzZ3H3H5h81NFynH0=E49NKSEpGdgYcchMcHEA3ng at mail dot gmail dot com> <20130424052055 dot GA4733 at domone dot kolej dot mff dot cuni dot cz>
On 24 Apr 2013, OndÅej BÃlka told this:
> On Tue, Apr 23, 2013 at 05:53:05PM -0400, Xinyang Ge wrote:
>> Thank you, Carlos.
>>
>> I think the preload way is cleaner and doesn't require recompilation
>> of glibc. However, will there be any symbol conflict between my
>> library and glibc since both have the open() function? How do dynamic
>> linked library avoid symbol conflict? I am really newbie in this
>> field, could you recommend some reading materials to me if possible?
>>
> On conflict resolution symbol that is loaded first wins.
That's not true in general. The ELF rules are much more complex,
since they have to take into account \( .. \) (DT_GROUP), -Bsymbolic,
libraries loaded with dlmopen() and so on.
But, in general, if you avoid all of that, the rules for shared
libraries appear to be the same as for static libraries: i.e., symbols
appearing in libraries specified earlier on the link line take priority
over symbols appearing in libraries specified later.
--
NULL && (void)