Organization and symbol lookup for shared libraries
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.
More information about the Java