1. Home
  2. Embedded Linux
  3. SOLVED: rashing dlopen() on Sharp Zaurus C860

SOLVED: rashing dlopen() on Sharp Zaurus C860

Dear all, I have found the reason. It is not really a bug in dlopen() but something I would consider a weakness. It turned out that -fPIC was missing when linking the libraries that later failed. Why this crashes *sometimes* and not always is someting I don't really understand. And there *might* or *should* be a flag within an executable file that tells if it was compiled -fPIC or not. And dlopen() *should* complain if it can't properly relocate such a module.

Thanks to all who have given me support!

Nikolaus Schaller

Reply to
Dr. Nikolaus Schaller
Loading thread data ...

The PIC flag forces the compiler to generate position-independent code. The non-PIC code may be mapped to the location the linker guesses for it, or it may end up in a different location. In the first caes it does not crash, in the second case it quite probably will crash (the crash is not 100% sure, as much of the code may happen to be position-independent, anyway).

Why are the shared libraries mapped to surprising addresses?

The shared libraries are used in different processes in different combinations. There are simply too many shared libraries to allocate an own address range to each, so they have to be mapped to the free address space available with the process. This means that when the library is used by many processes, it pretty probably is run at different linear addresses at each process.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.