On Tue, Mar 22, 2005 at 11:48:19AM -0700, Tom Tromey wrote:
> Andrew> Anthony Green has raised valid concerns
> Andrew> about multilib systems.
>
> I looked at the current gcc4.spec a little. It seems to me that we
> will have to just put the host architecture name into the path to the
> .db file. Assuming that would work, I don't really know about RPM
> multilibs.
>
> I CC'd Jakub for advice. Jakub, what should we do to make the
> built-in .db file work with multilibs? I will implement whatever it
> is we need.
Well, first you want to decide whether you want one master .db
file or one .db file per architecture.
One master .db file might be a tiny bit slower (since the .db file
will be bigger), but might be easier for users (e.g. gcj-dbtool -p
would be usable).
You just need to pick up some magic values for the architectures
(say for ELF architectures you can e.g. use the EM_* constants ored
with ELFCLASS{32,64} shifted up or something), add code that at configure
or compile time stores the current arch magic number into libgcj.so
(or wherever the code that will parse the .db file lives) and code
into gcj-dbtool to compute the magic value for a given shared library.
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>.
The first approach is what e.g. ldconfig/ld.so use.
Jakub
