This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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>
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |