Organization and symbol lookup for shared libraries
James Damour
jdamour@nycap.rr.com
Tue Nov 9 12:55:00 GMT 2004
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. 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).
--
James Damour (Suvarov454) <suvarov454@users.sourceforge.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20041109/b82a6a3f/attachment.sig>
More information about the Java
mailing list