Hello Greg, Thanks for you your reply. It help me to better express my question
From the application I can access /proc/self/maps and see which memory is mapped for my library I do not intend to use after application passes init phase. I would like to unmap this memory region, but since I do not have file descriptor for this so I can not do this. Only kernel can unmap this memory for me, I am willing to pass library name or address to system cal, but IMHO such system call does not exist. Should I rely on memory manager which will use reuse this pages because they will never page faulted back ?
I am afraid that since this is C++ lib, some pages are modified and will not be considered clean ? Thanks again for your precious time. Perhaps somebody from the list can respond too. Thank you all Lev 21.12.2018, 18:31, "Greg KH" <greg@kroah.com>:
On Fri, Dec 21, 2018 at 05:20:36PM +0300, Lev Olshvang wrote:
Hi All,
I have an executable (C++) which is the exclusive user of the some shared library that it uses only during the initialization phase.
I would like to free memory used by this shared library, because I am running on embedded system.
How can I achieve this?
I know that dlopen() will load shared library, and hope that following dlclose() will free this lib memory.
That right there is how you "achieve" this, call dlclose() and all will be fine. If your system needs the memory that was being used, it will reclaim it from the memory that was previously being used by the library at this point in time.
Nothing else needs to be done.
Have you tested this and found it not to work properly?
1. Still I do not know what method should be used to make dynamic linker look again into executable and resolve symbols of the newly appeared symbols ?
What "newly appeared symbols"?
If you need to load the library again, call dlopen().
2. And how to tell the dynamic linker ld-linux.so to postpone the symbol resolution until dlopen() will load the library?
It will not happen until you tell it to, right?
3. Whether to compile and link executable with this library or leave unresolved symbols?
It sounds like you don't really know what type of problem you are trying to solve here.
Back up, what is the real issue you are having with the kernel at this point in time?
thanks,
greg k-h