Organization and symbol lookup for shared libraries

Andrew Haley aph@redhat.com
Tue Nov 9 13:24:00 GMT 2004


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.



More information about the Java mailing list