I'm runtime linking (dlopen and dlsym) to a shared object (library) I've created and after a number of function calls into the library the program core dumps (Illegal operation). This only occurs during runtime linking. If I use the same library and dynamically link during compile time everything works perfectly.
I've tried different compilers and linking modes, but nothing seems to work. Lately I've been checking my code for bugs even though it's odd that everything works except during runtime linking.
Has anyone experienced anything like this and know what the problem/solution is.
Sadly, buggy programs are not guaranteed to fail. Somewhere in your program is a bug and you need to find it. For example, maybe a pointer has a bad value, but you are using it to store something. This overwrites something that it shouldn't. When you staticly link the program, you may be stepping on something that you don't need. But generate position independent code, and now you're clobbering something important.
The good news is that you have found a way to reliably expose the bug. The next step is to remove the bug.
The illegal operation sounds like you nailed a return address on the stack.
And yes this sort of thing happens to me a lot, although it's usually a program that works on hp but not sun (or vice versa). And it's always a bug a in my code. For this reason, I try my program on both systems as a quality check.
I'm currently checking my code for bugs because that's always usually the problem. However, know that I'm not doing a static link at all. The compile link and runtime link are both dynamic to the same -fPIC compiled library. And the only difference between the two types of links that I know of is that the library is loaded with the executable by default on a compile link and at my discretion on a runtime link. Also the code runs totally fine on Win32 no matter what kind of linking I do. It also runs fine with a compile link (dynamic) on the Dec Alpha unix platform. Granted the library I've written is extremely complex, so the chance of bugs are great, that just seems odd to me.
The code is running fine in all situations except this one so I'm trying to be sure I am not missing something when it come to runtime linking on Unix, like a buggy operating system library loader, a linking step, or something.
The relocation table of a shared object is not updated properly via the run-time linking method (dlopen). This means the calling process can make function calls into the shared object fine, but the shared object can not call it's own functions unless they are local/static because they have the wrong address location in the relocation table (illegal exception).
One solution is to build the shared object using a mapfile specifying all the funcions as local. However, make the shared object's interface (functions that will be called by a another process) global but call a local function that does the actual work. This means you will actually have two function (a global and local) doing the same thing.
Keep in mind there are other solutions depending on your situation. This is the one that worked for me because of the complexity of my shared object. If you have a one module shared object the mapfile can be eliminated by making functions local using the modifier static (a c/c++ key word).
