On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote:
> On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote:
> > With per-arch .db you could e.g. store the file into
> > /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be
> > gcc $CFLAGS -print-multi-os-directory (well, even better the path
> > would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory`
> > string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with
> > gcj-dbtool -p <arch>.
>
> I'm not sure I understand this second part.
>
> What's wrong with...
>
> /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db
>
> ?
>
> "gcj-dbtool -p <arch>" sounds hard to implement.
You mean that gcj-dbtool -p would print
/usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db
and you'd need to pass that through shell after making sure $CC and $CFLAGS
are properly defined?
Then you'd put the burden on rpm packagers, because in rpm %post
$RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require
gcc to be installed just to install Java packages).
Reminds me, gcj-dbtool should be probably moved from gcc-java subpackage
to libgcj now that it is used not only during compile time.
Jakub
