* E.B. Dreger <[EMAIL PROTECTED]> [020402 10:29] wrote:
> Greetings all,
>
>
> I wish to accomplish the following:
>
> 1. Program "foo" loads shared object "bar" using dlopen() and
> dlsym()
>
> 2. "bar" needs certain symbols resolved, which "foo" intercepts.
>
> For example, "foo" might wrap malloc() or open() to provide its
> own behavior... much like subclassing window procedures on that
> OS from Redmond, only I'm wrapping library calls instead of
> window callback procedures.
>
> Any suggestions, or should I get busy hacking ld-elf.so?
>
> And, yes, I know that one must be very careful when playing with
> fire. If anyone wishes to tell of monsters or horror stories,
> I'd appreciate those as well.
>From the dlopen manpage:
If dlsym() is called with the special handle RTLD_NEXT, then the search
for the symbol is limited to the shared objects which were loaded after
the one issuing the call to dlsym(). Thus, if the function is called
from the main program, all the shared libraries are searched. If it is
called from a shared library, all subsequent shared libraries are
searched. RTLD_NEXT is useful for implementing wrappers around library
functions. For example, a wrapper function getpid() could access the
``real'' getpid() with dlsym(RTLD_NEXT, "getpid").
How does that sound?
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
