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@xxxxxxxxx>: > 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
