C function conflict

Question

What should I do if I have two libraries that provide functions with equivalent names?

Answer 1

Swear? As far as I am aware, there isn't much you can do if you have two libraries that expose link points with the same name and you need to link against both.

Answer 2

You should not use them together. If I remember correctly, the linker issues an error in such a case.

I didn't try, but a solution may be with dlopen(), dlsym() and dlclose() which allow you to programmatically handle dynamic libraries. If you don't need the two functions at the same time, you could open the first library, use the first function and close the first library before using the second library/function.

Answer 3

• If you control one or both: edit one to change the name and recompile Or equivalently see Ben and unknown's answers which will work without access to the source code.
• If you don't control either of them you can wrap one of them up. That is compile another (statically linked!) library that does nothing except re-export all the symbols of the original except the offending one, which is reached through a wrapper with an alternate name. What a hassle.
• Added later: Since qeek says he's talking about dynamic libraries, the solutions suggested by Ferruccio and mouviciel are probably best. (I seem to live in long ago days when static linkage was the default. It colors my thinking.)

Apropos the comments: By "export" I mean to make visible to modules linking to the library---equivalent to the extern keyword at file scope. How this is controlled is OS and linker dependent. And it is something I always have to look up.

Answer 4

This problem is the reason c++ has namespaces. There's not really a great solution in c for 2 third party libs having the same name.

If it's a dynamic object, you might be able to explicitly load the shared objects (LoadLibrary/dlopen/etc) and call it in that fashion. Alternately, if you don't need both libs at the same time in the same code, you can maybe do something with static linking (if you have the .lib/.a files).

None of these solutions apply to all projects, of course.

Answer 5

I've never used dlsym, dlopen, dlerror, dlclose, dlvsym, etc., but I'm looking at the man page, and it gives an example of opening libm.so and extracting the cos function. Does dlopen go through the process of looking for collisions? If it doesn't, the OP could just load both libraries manually and assign new names to all the functions his libraries provide.

Answer 6

You should write a wrapper library around one of them. Your wrapper library should expose symbols with unique names, and not expose the symbols of the non-unique names.

Your other option is to rename the function name in the header file, and rename the symbol in the library object archive.

Either way, to use both, it's gonna be a hack job.

Answer 7

Here's a thought. Open one of the offending libraries in a hex editor and change all occurrences of the offending strings to something else. You should then be able to use the new names in all future calls.

UPDATE: I just did it on this end and it seems to work. Of course, I've not tested this thoroughly - it may be no more than a really good way to blow your leg off with a hexedit shotgun.

Answer 8

It is possible to renames symbols in an object file using objcopy --redifine-sym old=new (see man objcopy).

Then just call the functions using their new names and link with the new object file.

Answer 9

Under Windows, you could use LoadLibrary() to load one of those libraries into memory and then use GetProcAddress() to get the address of each function you need to call and call the functions through a function pointer.

e.g.

HMODULE lib = LoadLibrary("foo.dll");
void *p = GetProcAddress(lib, "bar");
// cast p to the approriate function pointer type (fp) and call it
(*fp)(arg1, arg2...);
FreeLibrary(lib);

would get the address of a function named bar in foo.dll and call it.

I know Unix systems support similar functionality, but I can't think of their names.