prevent linking of some functions in a shared library

[luk.bettale]

Hi,

I was wondering if it is possible to prevent linking of some functions in a .so library. Let me explain myself:

I have a file test.c which contains this:
#include <stdio.h>
void f1 (int a) { printf ("this is %d\n", a); }

a file test2.c which contains this:
void f1 (int);
void f2 (int a, int b) { f1 (a + b); }

I compile both files with -fPIC, then I produce 2 libraries, a static one, and a dynamic one:
ar cr libtest.a test.o test2.o && ranlib libtest.a
gcc -fPIC -shared -o libtest.so test.o test2.o

I have a main file using this library:
void f1 (int);
void f2 (int, int);
int main (int argc, char *argv[])
{
f1 (3);
f2 (3, 4);
return 0;
}

Everything is good, whether I perform static or dynamic linking, the program outputs this:
this is 3
this is 7

Now, *without modifying existing code*, I want to wrap the function f1 in a function of mine which needs also to execute the "real" f1. I write the file wrapped.c as follows:
#include <stdio.h>
void __real_f1 (int);
void __wrap_f1 (int a)
{
printf ("wrapped !! ");
__real_f1 (a + 42);
}

and I link main.c and wrapped.c with libtest using the option -Wl,-wrap,f1.
with static link, I obtain
wrapped !! this is 45
wrapped !! this is 49

with shared link, I obtain
wrapped !! this is 45
this is 7

What happened ?
Simply, in the static lib libtest.a, no link edition has been performed (it is just a collection of .o files). Everything is done at link time at the end, and f1 is wrapped everywhere.
On the contrary, in the shared library, partial linking has already been performed, in particular, the call to f1 in the function f2 has been mapped to the code of the "real" f1 from libtest.so. This explains the obtain results.

My question:
Is it possible to prevent this behavior ? (at least for exported functions)
A solution would be to split libtest into two separate .so files, but I would like to do this with only one .so file if possible.

I tried some linker options without success. I have also searched the web without success...

Thank you

 

[greg.king5]

I was wondering if it is possible to prevent linking of some functions
in a .so library. Let me explain myself:

I have a file "test.c" which contains this:

#include <stdio.h>
void f1 (int a) { printf ("this is %d\n", a); }

a file "test2.c" which contains this:

void f1 (int);
void f2 (int a, int b) { f1 (a + b); }

I compile both files with -fPIC; then, I produce 2 libraries, a static one, and a dynamic one:

ar cr libtest.a test.o test2.o && ranlib libtest.a
gcc -fPIC -shared -o libtest.so test.o test2.o

I have a main file using this library:

void f1 (int);
void f2 (int, int);
int main (int argc, char *argv[])
{
f1 (3);
f2 (3, 4);
return 0;
}

Everything is good; whether I perform static or dynamic linking,
the program outputs this:

this is 3
this is 7

Now, *without modifying existing code*, I want to wrap the function f1
in a function of mine which needs also to execute the "real" f1.
I write the file "wrapped.c" as follows:

#include <stdio.h>
void __real_f1 (int);
void __wrap_f1 (int a)
{
printf ("wrapped !! ");
__real_f1 (a + 42);
}

And, I link "main.c" and "wrapped.c" with libtest using
the option "-Wl,-wrap,f1".

With static link, I obtain:

wrapped !! this is 45
wrapped !! this is 49

With shared link, I obtain:

wrapped !! this is 45
this is 7

What happened?

Simply, in the static lib. "libtest.a", no link editting has been performed
(it is just a collection of .o files). Everything is done at link time,
at the end; and, f1 is wrapped everywhere.
On the contrary, in the shared library, partial linking has already been
performed; in particular, the call to f1 in the function f2 has been mapped
to the code of the "real" f1 from "libtest.so". That explains the obtained
results.

My question:
Is it possible to prevent that behavior (at least, for exported functions)?

A solution would be to split libtest into two separate .so files;
but, I would like to do it with only one .so file if possible.

I tried some linker options without success. I have also searched the web
without success.

Apparently, the (Cygwin) linker that I use does things in the opposite way. The descriptions of one gcc option (-symbolic) and two ld options
(-Bsymbolic-functions and -Bsymbolic) imply that the linker usually _doesn't_ do partial linking in shared libraries. We explicitly must command the partial linking.