Re: C Linker/Compiler question

> Hi ! Thank you for your answer. The real goal is to put myself between
> an application and a library. One solution I thought of, as a first
> approch, is :
>
> -----------
> --------->| my_lib1 |
> | -----------
> ------- | |
> | app |---------- |--> defines symbol a() that calls my_a()
> ------- | =
>
> | | -----------
> | --------->| my_lib2 |
> | | -----------
> | | |
> | | |--> defines symbol my_a() that calls a()
> | | ** would like to call the one in real_lib !! **
> | |
> | | ------------
> | --------->| real_lib |
> | ------------
> | |
> | |--> real definition of a()
> |
> |--> symbol a() from my_lib1
>
> The problem is that NO link related job is done when the libraries are
> constructed. Therefore when all this code is really linked in app,
> only the first definition of a() is used. What I would like to do is
> to construct my_lib2 so that the call to a() is resolved right away to
> the address in real_lib. Is it reasonable ? Is "partial linking" the
> solution ? Is it safe to use ld when the objects files had been
> constructed with another tool, say KCC or anything other ?
>
> Notice that there might be one superfluous library in this scheme.
> my_lib2 could probably be replaced by a "special" object file where
> the symbol "a()" had been resolved once and for all to the one in
> real_lib. But the problem is the same.
>
> One solution would be to use dynamic linking. my_a() would explicitly
> ask the runtime dynamic linker the address of a() in real_lib and call
> it. This will probably work. But what if I real_lib only comes as a
> static library ?


> [This is a problem that few linkers solve well. The most common workaround
> is to give library routines long ugly names that are unlikely to collide
> with names in user applications. -John]


If I understand you correctly, you're really just looking to do a
simple wrapping trick, oui? _That_ can be accomplished very easily
<caveat>providing you're on a platform that supports dlopen/dlsym with
the RTLD_NEXT option </caveat> Basically, the function a() in lib1
would look like this:


return_type a() {
static return_type(*real_a)(void) = NULL;
return_type result;
if ( !real_a ) {
real_a = (return_type(*)())dlsym("a",RTLD_NEXT);
/* handle error conditions, of course */
}
/* do some stuff */
result = real_a();
/* do some other stuff */
}
It's just a standard interposition trick, where you're using link order
to resolve things the way you want, i.e.
cc -o whatever ... -l1 -lreal
where lib1.so holds the wrapper functions and libreal.so the ones you're
wrapping.


In the case where you're dealing with static libraries, there's a linker
option "--wrap symbol" (see the docs).


There's also a method using the LD_PRELOAD directive, where you use
you're wrapper library as the preload (zlibc uses this trick--as, um, we
do).




HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu

Return to the comp.compilers page.
Search the comp.compilers archives again.