> ./main: error while loading shared libraries: ./main: failed to map segment from >shared object: Error 1073741869
That value is EOPNOTSUPP (I used "p (error_t)1073741869" in gdb). > > Also, show us objdump --private-headers of both executables. This stuff is probably not actually relevant in this case, now that we know mmap is failing. But it's good information to have on hand. > I hope I've captured the right things here. I don't really understand > too much of what I'm looking at. When I'm stepping through with gdb, > it appears to skip some lines, so I had to refer back to the source to > figure out where OutP was defined. You're still giving both too much and too little information. Step into mmap, then next over the functions it calls to see which one fails. Then (in an other debugging iteration) step into that one, etc. Another useful gdb command is "finish", which is what I kept wishing I could type at your gdb prompts as you step through __io_map. :-) I hope that stepping through the stubs added to your understanding of how RPC's are marshalled into Mach messages. But the upshot is that the io_map RPC is returning EOPNOTSUPP. (And the easy way to see that in the debugger is from the mmap frame when io_map returns.) So, uh, these "./mutt" and "./main" aren't actually in the same ".", are they? Is one of them NFS? I guess I should have mentioned that yesterday when it seemed the most likely reason for mmap to be failing. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
