Chris Plummer wrote: > > Thiemo Seufer wrote: > > > > Chris Plummer wrote: > > [snip] > > > (gdb) bt > > > #0 0xffffffff in ?? () > > > #1 0x2aab73c8 in _dl_init () from /lib/ld.so.1 > > > Cannot access memory at address 0x38 > > > (gdb) p $pc > > > $1 = -1 > > > (gdb) > > > > It looks like the dynamic loader forgot to resolve a function entry. > > Can you try to reduce your App to the smallest testcase where this > > problem occurs? > > > > Thiemo > > > Certainly I can try, but it could take a while. This is a very big > program, and heavily interconnected. > > Your suggestion to use -static for my -mips2 problem got me thinking > that maybe I should try that here also so there are no dll's to load. > This indeed has fixed the problem. However, this program also requires > --export-dynamic to lookup some of its own symbols, and -static seems to > override --export-dynamic and prevent any exports, so now it gets the > following error from dlopen: > > Fatal Error: Could not open testapp as a shared library > > In any case, this is a good start. I'll play around with linker flags a > bit more. I'm still not sure if it is the presence of -static or the > lack of --export-dynamic that is making the problem go way. In a worse > case senario I can create a static table of all the symbols the program > looks up, and just replace dlsym calls with table lookups. > > thanks for the help, > > Chris
Removing -export-dynamic does not fix the problem. The -static is needed, so it looks like this is related to resolving one of the imported symbols. At this point I don't need to resolve this any further because it turns out we're ok linking with -static and not having -export-dynamic. However, if anyone has something they want me to try, I'd be more than happy to, along as it isn't going to be too time consuming. Chris Plummer
