Is there a way to build a non-PIC shared library with l4env?

Valery V. Sedletski _valerius at
Tue Oct 11 07:15:57 CEST 2011

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

More information about the l4-hackers mailing list