Organization and symbol lookup for shared libraries

Tue Nov 9 19:27:00 GMT 2004

Andrew Haley wrote:
>James Damour writes:
> > Bryce McKinlay writes:
> > > Perhaps this step (running gcj-dbtool) could be avoided altogether: if 
> > > the cache is found to be out-of-date at runtime, because someone added 
> > > or changed a shared library without re-running dbtool, then we'll need 
> > > to open those modified shared libraries at runtime anyway. Since we have 
> > > to open them, the runtime could simply update the cache file on-the-fly?
> > 
> > The problem with that is permissions.
>>What should happen in this situation is for libgcj to fall back to 
loading the shared libraries without the cache, and print a warning that 
the cache file needs to be updated by running gcj-dbtool.
One thing we do need to consider carefully, though, is security - we 
don't want a suid root gcj application blindly opening shared libraries 
from user-writable directories!
>Also, there's a potential issue with shared access. I'm not
>sure it's wothwhile.
>>I don't see what the problem is with sharing. Surely, provided the cache 
file is updated atomically, it will never be seen in an inconsistent state?
Regards
Bryce