Linker problems in REL 2.4.21-4
I am migrating one application from unix to linux. The executables are built successfully, but at runtime they are giving problems. I have discovered that there is some issue with linux linker. I think it has a very limited memory space. Thats why it does not read the symbols which are there in executable but high up in memory space.
Once I had to statically link on .o in the build file of executable (although that .o was present there in one shared library which was linked into the built file). The linker was not able to call the function from one .o to that .o and was calling some other function.
Is there any way to solve this problem or increase linker memory space ?
# 1
Linker behaviour is not very obvious in some cases. For example, if your executable depends on some library that defines, say, a function named foo() and executable also has this (non-static) function, then when you call foo() from a library, executable's foo() will be called. Maybe smth like this happens with your app?
I don't know much about Linux linker, but there should definitely be some manpage on ld.so and linker and libraries guide of some kind.
# 3
A segmentation fault (SEGV) occurs when a program tries to access memory that does not belong to the process, or an otherwise invalid address.
SEGVs are usually due to programming errors, and they usually happen far away in space and time from the actual error. They are hard to find. Some common causes of SEGVs:
- using an uninitialized variable
- using an object that has gone out of scope or that has been freed
- freeing an object more than once
- freeing an address that was not acquired from the corresponding malloc
- writing beyond the bounds of an object
If a program is multi-threaded, SEGVs can result when access to shared data is not properly synchronized.
These programming errors do not always cause SEGVs. For example, an invalid pointer might by accident point to a harmless location. But any change in the program, compiler, compile-time options, link sequence, or system can change whether an invalid pointer is harmless or harmful.
The debugger (dbx) can help you find these problems. Turn on Run-Time Checking, and watch for complaints. If you get a SEGV without a complaint, track down where the invalid reference occurred by using conditional breakpoints and data watchpoints.
You said earlier that the linker was not linking your program the way you expected. If that is still a problem, it could also be the ultimate cause of a SEGV. For example, if you have conflicting functions "foo" and the wrong foo gets called, bizarre things can happen. The debugger can also show you exactly which function is being called.
