How to know which 'sin' function does my program invoke when running?

Question

I am using different versions of libm.a. One that I am playing with is fdlibm's libm.a (from Sun).

The problem is that I feel that my program does not call the functions in fdlibm's libm.a, but calls those of the system's glibc's libm.a.

#include "fdlibm.h"
int main(){
  double x = sin(3);
}

The program is compiled C++ programs(because it has to be linked with other c++ programs):

g++ prog.cpp libm.a

where libm.a is the fdlibm's. (From Sun, http://www.netlib.org/fdlibm/readme)

Question 1

How can I know what does sin actually invoke at run-time? I heard about various tools like objdump, gdb... Which one can be used for my case and how?

Question 2

How can I enforce fdlibm's libm.a be used?

Thanks.

Answer 1

Question 1. I heard about various tools like objdump, gdb.

As with gdb. Create file trace_sin.gdb

$ cat trace_sin.gdb
set confirm off
b sin
commands
bt
c
end
r
quit

And run your program:

$ gdb -q -x trace_sin.gdb   ./a.out Reading symbols from ./a.out...(no
debugging symbols found)...done. Breakpoint 1 at 0x400498

Breakpoint 1, 0x000000314941c760 in sin () from /lib64/libm.so.6
#0  0x000000314941c760 in sin () from /lib64/libm.so.6
#1  0x0000000000400629 in main ()

As you see in my case sin comes from libm

Question 2. How can I enforce fdlibm's libm.a be used?

Just make sure than sin from fdlibm comes before libm's sin

Answer 2

I have used the following simple technique to 'gently specify' (not explicit) a library needed for link. This technique might be appropriate for you.

I had already created several libraries which I had to use, and they were all in one specific path: "/home//cvs-tools/lib1". )

When it came time to use the 1 boost lib I needed, I simply copied the latest libboost_chrono.a into "/home//cvs-tools/lib1". No .so in the way.

And touched my make files so that when I updated boost, rather than me trying to remember all implications, I simply added to my make file the copy of chrono.a to my lib1, and my normal build then updated lib1's copy.

So, by 'gently specific', I mean that a) my make file copied the b) specific COTS library (boost) into c) my lib1 directory, and thus picked up by the same -L.

Answer 3

I grew tired of linking/deferred loading of the .so version of a library, and somewhere I found that you can achieve a link to a specific libary, by specifying path to the library.

Perhaps this can help with your challenge.

example - I can change this command (and link to SDL2 .so)

$(CC) $(CC_FLAGS)  $<  -o $@  -L../../bag  -lbag_i686 -lSDL2

and achive the same with

$(CC) $(CC_FLAGS)  $<  -o $@  -L../../bag  -lbag_i686 /usr/local/lib/libSDL2.so

Explicitly identifying which lib to use.

---

On ubuntu, I can use 'locate' to find the full path of a file. It turns out that SDL2 (.so) lands in both /usr/local/lib and /usr/lib/x86_64-linux-gnu. I suppose the x86_64 is more appropriate for my system, and it also links.