On Mon, 10 Oct 2011 11:19:17 +0200, Adam Lackorzynski wrote:
But l4rm must be a single instance in a single application, so I need to use an l4rm instance from my application, not in a shared lib... So, I need somehow to call my application region mapper from the shared lib... But I cannot use the ldso for linkage. So I need to make the linkage manually... I see only one solution: to pass the needed l4rm function pointers to the shared lib 'init' function. But maybe, the better solution exists? Any ideas?
Sounds hacky but I cannot provide an alternative. I think you lost me a bit wrt your current setup, so if your solution works for you I'm happy.
Yes, it almost works now -- I made the pointers to l4rm functions and some other ones, passed to the 'init' function in the shared library. So, I fixed the unresolved symbols, now application loads successfully. But it seems that some variables remained uninitialized -- when I call a function from the shared lib, which allocates memory, and calls malloc() for that, I got a message from libc (the minicmd is my OS/2 application):
minicmd | mmap(): mmap, fd: 0, flags: 34
and then from 'loader' server:
loader | os2app,#17: Not allowed to perform any I/O
Regarding the loader message, it seems that the app accessed a random region in an I/O memory because of uninitialized variables. But why mmap to fd: 0, I cannot say. fd=0 is stdin, but I know that malloc accesses the heap but why it uses a memory-mapped files I yet don't know. So, some troubles are still there, but I hope I'll work it out
(Note: os2app is the same app as minicmd.exe, I just chagned the log tag, but 'loader' server uses an old one) Still cannot say any more details, will investigate with a debugger