Hi all,

I have a problem where i need to find to what library my code links to.
Here is the scenario:
a) I have two executables. Both link to pthread. But pthread seems to behave differently.
b) I am not sure that they are linking to the same version or the same pthread library.
c) Assuming there are different versions of the lib, i maybe linking to different libs.
d) Right now, i have no way to check this. The code size is massive and I don't know where to find linker paths etc..

So, here's what i did:

void print_func(void* code)
{
    int i;
    printf("\nFunc code:\n");
    printf("\n==============================\n");
    char* data = (char*)code;
    for (i = 0; i < 100; i++) { //just print some 100 bytes in code definition.
        printf(" %3d ", *data++);
    }
    printf("\n==============================\n");
}


void mut_init(pthread_mutex_t* mutp)
{
    // Some init code..

    // Print code.
    {
        // Print out code definitions for some pthread functions..
        print_func(pthread_func_1);
        print_func(pthread_func_2);    

        // Print the code defintion for printf..
        print_func(printf);
    }
}

I do the same for both executables. As I'd expected, the printf code definitions are the same(so, the libc library is the same), however the pthread code defintions seem to differ.

Now, my questions.
1) Is this a foolproof way to check that I'm linking to different libs?
2) If not, can you please explain what is wrong with this approach? It's just a quick experiment that i did.

Edited 2 Years Ago by myk45

On a typical *nix installation, ldd executableName will give you a listing of the dynamic libraries it uses.

What Moschops suggests is correct. However, there are other things that may complicate the process. There is an environment variable (LD_PRELOAD) that allows you to change the order of loaded libraries of a compiled executable. In addition to that, your codebase may change the definition of a function via #define or similar mechanism.

You can look at dlopen or dlsym and check the actual resolved/relocated symbol that gets returned at runtime.

I'd like to suggest, however, that select isn't broken. Expecting that there are multiple libraries behaving differently from with the same application is an unlikely scenario unless some non-standard approaches are being used within that application.

It is more likely that you have a subtle bug that is not apparant to you. Unfortunately, with multithreaded applications this is even harder to track down.

This article has been dead for over six months. Start a new discussion instead.