Re: Organization and symbol lookup for shared libraries

[Andrew Haley <aph at redhat dot com>]

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.

Indeed.  Also, there's a potential issue with shared access.  I'm not
sure it's wothwhile.

 > I'd imagine that /usr/lib/gcj would only be writeable by root, so I
 > (a shmuck app developer) wouldn't be able to update the cache file
 > when I run my app.  I'd rather see "update cache file" be a step in
 > the RPM (or, more accurately, DEB:) installation process; that
 > implies the "cd /usr/lib/gcj; make" solution (or something along
 > those lines).

That was my intention.  However, shmuck app developers would still
have local caches, so there is some scope for what Bryce suggests.

Andrew.