- Forum
- UNIX/Linux Programming
- Call to function of linked dynamic libra
Call to function of linked dynamic library does nothing???
Hi All,
I have a very weird problem when calling a function from a dynamic library, that is linked to my program. It's a very simple function. It just takes an object, alters its contents and returns. At least, it should do so. Instead, when calling the function, it does nothing and simply returns without altering the contents of the passed object. I tried to compile the library with debugging information and during debugging tried to step into the function when it is called, but the debugger doesn't step into the function and just continues with the next instruction. I would say, I'm an experienced developer, so generally I know how to handle stuff, but I don't have a clue in this case. I read something about linkage with weak references. And a 'nm --demangle' on the shared library sais the Objects ,the function that I'm calling is a memeber of, has a 'V' in front of it, which has something to do with weak references. Could it have something to with that? I'm thankful for any help.
-Christian
I have a very weird problem when calling a function from a dynamic library, that is linked to my program. It's a very simple function. It just takes an object, alters its contents and returns. At least, it should do so. Instead, when calling the function, it does nothing and simply returns without altering the contents of the passed object. I tried to compile the library with debugging information and during debugging tried to step into the function when it is called, but the debugger doesn't step into the function and just continues with the next instruction. I would say, I'm an experienced developer, so generally I know how to handle stuff, but I don't have a clue in this case. I read something about linkage with weak references. And a 'nm --demangle' on the shared library sais the Objects ,the function that I'm calling is a memeber of, has a 'V' in front of it, which has something to do with weak references. Could it have something to with that? I'm thankful for any help.
-Christian
Last edited on
I'm passing only pointers. I'm absolutely sure, I'm doing everything right on the coding side. I would say, I'm an experienced programmer and I work with c++ for several years now.
I tried to stuff the called function of the shared library with some debugging output. When calling the function there is no output. It really seems the code of the function simply isn't executed when calling the function. So I strongly assume it has something to do with the linking. Is there any way to examine the compiled execute and library to see, if everything is linked correctly?
I tried to stuff the called function of the shared library with some debugging output. When calling the function there is no output. It really seems the code of the function simply isn't executed when calling the function. So I strongly assume it has something to do with the linking. Is there any way to examine the compiled execute and library to see, if everything is linked correctly?
I found something new. It seems the symbols in the shared library are also defined in another shared library I'm linking to (but there in an older incompatible version). So I have an executable now, that links to two shared libraries and there are some symbols that are defined in both of those libraries. How can I make sure my executable links to the symbols in that shared library I want and not to the other?
Does the order of the -l flags during linking somehow affect this? For example assume I have two shared libs libA.so and libB.so and they both define partially the same symbols. Would may be
g++ -o exec -lA -lB exec.o
link exec to the symbols in libA.so whereas
g++ -o exec -lB -lA exec.o
link exec to the symbols in libB.so ?
g++ -o exec -lA -lB exec.o
link exec to the symbols in libA.so whereas
g++ -o exec -lB -lA exec.o
link exec to the symbols in libB.so ?
Mmm, dunno. If I can guess how symbols get resolved at link time, I'd say that whichever .so got loaded first at runtime would decide which function got called. I'm not sure if this is controlled by order of specification of libraries on the link line.
Hi,
What i have understood from the discussion is you are either not able to call a function in .so file or your passed object is not changing.
First you have to be sure if your code is executing or not. you can put a print inside the function. if its printed then your function is executing. that means now you have to concentrate on why the object is not changed.
i am sure you are not passing the object as value.
what you can do is first try to load dynamically using dlopen and dlsym. if the function is called successfully then nothing is wrong with the .so file. because i think your binary is linking to some wrong library and calling some wrong function.
What i have understood from the discussion is you are either not able to call a function in .so file or your passed object is not changing.
First you have to be sure if your code is executing or not. you can put a print inside the function. if its printed then your function is executing. that means now you have to concentrate on why the object is not changed.
i am sure you are not passing the object as value.
what you can do is first try to load dynamically using dlopen and dlsym. if the function is called successfully then nothing is wrong with the .so file. because i think your binary is linking to some wrong library and calling some wrong function.
Topic archived. No new replies allowed.