11:13 a.m.
This is a crude example of what we could have, but it's what I've got so
far:
%post -n %{libname}-gtk2
if ![ -e `gcj-dbtool -p` ]; then
dirname `gcj-dbtool -p` | xargs mkdir -p;
gcj-dbtool -n `gcj-dbtool -p`;
fi
if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then
gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db`
`gcj-dbtool -p`
fi
%postun %{libname}-gtk2
if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then
gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name \*.db`
`gcj-dbtool -p`
fi
I'm not even sure if what I have will work. I'd just like to start the
discussion about how best to do it. Anthony Green has raised valid concerns
about multilib systems.
Andrew
12:48 p.m.
>>>> "Andrew" == Andrew Overholt
<overholt(a)redhat.com> writes:
Andrew> This is a crude example of what we could have, but it's what
Andrew> I've got so far:
Looks ok overall. I would probably put the result of `gcj-dbtool -p`
into a shell variable.
Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then
Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name
\*.db` `gcj-dbtool -p`
Andrew> fi
Is %{name} the name of the current RPM?
If so then I think this is incorrect. We need to merge everything
into the master .db.
Andrew> I'm not even sure if what I have will work. I'd just like to start
the
Andrew> discussion about how best to do it.
Can we get this in somewhere as an RPM macro? And, if so, where?
jpackage-utils? java-gcj-compat?
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.
Tom
12:58 p.m.
* Tom Tromey <tromey(a)redhat.com> [2005-03-22 13:55]:
Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ]; then
Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name
\*.db` `gcj-dbtool -p`
Andrew> fi
Is %{name} the name of the current RPM?
If so then I think this is incorrect. We need to merge everything
into the master .db.
We're merging into the master .db but until we sort out where to put the
other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings.
Andrew
1:06 p.m.
On Tue, 2005-03-22 at 13:58 -0500, Andrew Overholt wrote:
* Tom Tromey <tromey(a)redhat.com> [2005-03-22 13:55]:
>
> Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name \*.db`" ];
then
> Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name
\*.db` `gcj-dbtool -p`
> Andrew> fi
>
> Is %{name} the name of the current RPM?
> If so then I think this is incorrect. We need to merge everything
> into the master .db.
We're merging into the master .db but until we sort out where to put the
other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings.
Other than Anthony Green's response, there's not much opinion on that
yet it seems. Maybe asking the question was premature; it's something
I'd like to figure out sooner rather than later, though.
The only other thing was the `find %{_libdir}/%{name}/mappings -name
\*.db` potentially producing a list of db's that is to big to fit in the
argument buffer, and that may make an incorrect merge.
What are the advantages of an rpmacro over just placing a merge shell
script in /usr/bin?
Regards
Phil
6:37 p.m.
>>>> "Phil" == Phil Muldoon
<pmuldoon(a)redhat.com> writes:
Phil> What are the advantages of an rpmacro over just placing a merge shell
Phil> script in /usr/bin?
Just that it doesn't show up in the user's $PATH.
I don't know if that is a plus or a minus, honestly.
Wherever it ends up, it needs a sensible name.
Tom
1:20 p.m.
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
1:39 p.m.
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.
AG
1:50 p.m.
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
1:58 p.m.
Jakub Jelinek writes:
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?
gcj-dbtool is a target program, part of libgcj. So, on a multi-arch
system, would there not be two gcj-dbtools, linked against different
libgcjs? And, each one would print its *own* directory.
Andrew.
2:06 p.m.
On Tue, Mar 22, 2005 at 07:58:53PM +0000, Andrew Haley wrote:
> 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?
gcj-dbtool is a target program, part of libgcj. So, on a multi-arch
system, would there not be two gcj-dbtools, linked against different
libgcjs? And, each one would print its *own* directory.
On multi-arch systems, there is usually just one set of binaries and one
or two sets of libraries.
If you want 2 gcj-dbtool programs, that's of course possible, but you
need to decide where to install them (e.g.
/usr/libexec/gcj/$LIB/gcj-dbtool
), but then all the programs that want to use gcj-dbtool need to figure out
which one they want to call.
For %post this location wouldn't be that hard, rpm %post would just call
/usr/libexec/gcj/%{_lib}/gcj-dbtool -p ...
But, will you require all Makefiles that deal with gcj-dbtool to call
/usr/libexec/gcj/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-dbtool
?
Certainly, one master .db file, although it will need some work inside
gcj-dbtool and libgcj.so, will make things far easier for the users and
developers.
Jakub
2:11 p.m.
Jakub Jelinek writes:
Certainly, one master .db file, although it will need some work inside
gcj-dbtool and libgcj.so, will make things far easier for the users and
developers.
That's impossible.
The .db is a mapping from bytecode to shared objects, and there is no
guarantee that if a class exists in lib/foo.so it will also exist in
lib64/foo.so. However, that class might well exist in lib64/bar.so.
Andrew.
2:22 p.m.
On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote:
Jakub Jelinek writes:
>
> Certainly, one master .db file, although it will need some work inside
> gcj-dbtool and libgcj.so, will make things far easier for the users and
> developers.
That's impossible.
The .db is a mapping from bytecode to shared objects, and there is no
guarantee that if a class exists in lib/foo.so it will also exist in
lib64/foo.so. However, that class might well exist in lib64/bar.so.
Why impossible? If can be a mapping from <bytecode, arch> pair to
shared objects...
Jakub
2:44 p.m.
Jakub Jelinek writes:
On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote:
> Jakub Jelinek writes:
> >
> > Certainly, one master .db file, although it will need some work inside
> > gcj-dbtool and libgcj.so, will make things far easier for the users and
> > developers.
>
> That's impossible.
>
> The .db is a mapping from bytecode to shared objects, and there is no
> guarantee that if a class exists in lib/foo.so it will also exist in
> lib64/foo.so. However, that class might well exist in lib64/bar.so.
Why impossible? If can be a mapping from <bytecode, arch> pair to
shared objects...
Oh, what a horrible idea. Yes, that would work, I suppose. It
doesn't scale well, though.
I would have thought it easier just to give the db an appropriate name
for the arch. We don't use fat libraries, so why create fat
databases? The reasoning is exactly the same.
Andrew.
6:33 p.m.
>>>> "Jakub" == Jakub Jelinek
<jakub(a)redhat.com> writes:
Jakub> On multi-arch systems, there is usually just one set of binaries and one
Jakub> or two sets of libraries.
Programs like 'gcj-dbtool' and 'gij' are linked against a specific
libgcj.so. If there is only one set of binaries, then it seems like
we don't need to bother with multilib at all, since it will only ever
be possible to use one particular libgcj.so -- the one 'gij' is linked
to. At least, that is true in the common case... e.g., eclipse, which
in the end invokes 'gij' at startup.
Or am I missing some magic that lets us pick libraries at runtime?
I don't know how this could work, but I'm ready to be enlightened :-)
Tom
12:13 a.m.
On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote:
Programs like 'gcj-dbtool' and 'gij' are linked
against a specific
libgcj.so. If there is only one set of binaries, then it seems like
we don't need to bother with multilib at all, since it will only ever
be possible to use one particular libgcj.so -- the one 'gij' is linked
to. At least, that is true in the common case... e.g., eclipse, which
in the end invokes 'gij' at startup.
Or am I missing some magic that lets us pick libraries at runtime?
I don't know how this could work, but I'm ready to be enlightened :-)
What prevents other programs to use libgcj.so (or now that there is
libgij.so also libgij.so)?
And when they do, you don't know if those programs will be 32-bit or
64-bit.
Jakub
5:50 a.m.
Jakub Jelinek writes:
On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote:
> Programs like 'gcj-dbtool' and 'gij' are linked against a specific
> libgcj.so. If there is only one set of binaries, then it seems like
> we don't need to bother with multilib at all, since it will only ever
> be possible to use one particular libgcj.so -- the one 'gij' is linked
> to. At least, that is true in the common case... e.g., eclipse, which
> in the end invokes 'gij' at startup.
>
> Or am I missing some magic that lets us pick libraries at runtime?
> I don't know how this could work, but I'm ready to be enlightened :-)
What prevents other programs to use libgcj.so (or now that there is
libgij.so also libgij.so)?
Nothing.
And when they do, you don't know if those programs will be 32-bit
or
64-bit.
I don't understand purpose of this comment. If there's a 32-bit
multilib, the user will use -m32 at compile time, and that will link
with the 32-bit library.
Andrew.
12:28 p.m.
>>>> "Andrew" == Andrew Haley
<aph(a)redhat.com> writes:
> And when they do, you don't know if those programs will be
32-bit or
> 64-bit.
Andrew> I don't understand purpose of this comment. If there's a 32-bit
Andrew> multilib, the user will use -m32 at compile time, and that will link
Andrew> with the 32-bit library.
Jakub was responding to me, since I didn't see how people would end up
using the non-default libgcj.so. But his point is that some program
may link against it explicitly, or dlopen and use the invocation API.
And so, since we can't predict now which library might be used on a
fully installed system, we have to handle this somehow.
Anthony's gcj-dbtool patch went in, so we can start trying this soon.
(FWIW I also didn't like the idea of having the ABI recorded in the
.db.)
Have we worked everything out now? We solved the multilib problem,
and there seems to be a consensus on where to put the .so cache.
Tom
2:10 p.m.
On Tue, 2005-03-22 at 14:50 -0500, Jakub Jelinek wrote:
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).
This shouldn't require gcc at install time. We can create the
application specific classmaps at build time, and simply merge them at
install time.
AG
9:27 p.m.
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
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.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason)
"gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
This is convenient because it is easy to implement and easy to use.
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that
_libdir refers to the correct lib directory for the target ABI.
AG
12:42 p.m.
Anthony Green writes:
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
> 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.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason)
"gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
This is convenient because it is easy to implement and easy to use.
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that
_libdir refers to the correct lib directory for the target ABI.
That sounds pleasingly simple.
Andrew.
5:14 p.m.
On Wed, 2005-03-23 at 18:42 +0000, Andrew Haley wrote:
Anthony Green writes:
> On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
> > 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.
>
> After looking at this for a bit, I recommend the following:
>
> "gcj-dbtool -p" operates as usual (for no special reason)
> "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
[snip]
That sounds pleasingly simple.
There's a patch waiting for approval now:
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00886.html
Hopefully it will find its way into rawhide update sometime soon.
AG
12:53 p.m.
* Anthony Green <green(a)redhat.com> [2005-03-22 22:32]:
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
> 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.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason)
"gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
This is convenient because it is easy to implement and easy to use.
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that
_libdir refers to the correct lib directory for the target ABI.
This sounds good. Can we put a database subdirectory at the same location?
LIBDIR/gcj-VERSION/classmap.d
Andrew
1:22 p.m.
On Wed, 2005-03-23 at 13:53 -0500, Andrew Overholt wrote:
> The %post and %postun spec file sections can simply do:
>
> DB=`gcj-dbtool -p %{_libdir}`
>
> and use DB for the database name. Presumably rpm will make sure that
> _libdir refers to the correct lib directory for the target ABI.
This sounds good. Can we put a database subdirectory at the same location?
LIBDIR/gcj-VERSION/classmap.d
Yes - in my spec file proposal I used $DB.d.
AG
4:26 p.m.
Here's a real-world example from the servletapi5 spec file. It
currently assumes that we should be using `gcj-dbtool -p`.
Comments/suggestions welcome.
*** servletapi5.spec 2004-11-04 06:41:06.000000000 -0800
--- servletapi5.spec.new 2005-03-22 14:23:54.964489184 -0800
***************
*** 3,9 ****
%define name %{base_name}%{major_version}
%define full_name jakarta-%{base_name}
%define version 5.0.18
! %define release 1jpp_3fc
%define section free
Name: %{name}
--- 3,9 ----
%define name %{base_name}%{major_version}
%define full_name jakarta-%{base_name}
%define version 5.0.18
! %define release 1jpp_4fc
%define section free
Name: %{name}
***************
*** 23,29 ****
BuildRequires: xerces-j2, xml-commons-apis
BuildRequires: jpackage-utils >= 1.5.30
BuildRequires: java-javadoc
- BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
#Obsoletes: servlet4
#Obsoletes: servlet23
--- 23,28 ----
***************
*** 66,79 ****
--- 65,91 ----
ant dist -Dservletapi.build=build -Dservletapi.dist=dist
popd
+ # Generate native code.
+ gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o
libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar
+ gcj-dbtool -n jspapi-%{version}.db
+ gcj-dbtool -f jspapi-%{version}.db jsr152/dist/lib/jsp-api.jar
%{_libdir}/libjspapi-%{version}.jar.so
+ gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o
lib%{name}-%{version}.jar.so jsr154/dist/lib/servlet-api.jar
+ gcj-dbtool -n %{name}-%{version}.db
+ gcj-dbtool -f %{name}-%{version}.db jsr154/dist/lib/servlet-api.jar
%{_libdir}/lib%{name}-%{version}.jar.so
%install
cd jakarta-tomcat-%{version}-src/jakarta-servletapi-5
# jars
install -d -m 755 $RPM_BUILD_ROOT%{_javadir}
+ install -d -m 755 $RPM_BUILD_ROOT%{_libdir}
+ install -d -m 755 $RPM_BUILD_ROOT`gcj-dbtool -p`.d
install -m 644 jsr152/dist/lib/jsp-api.jar
$RPM_BUILD_ROOT%{_javadir}/jspapi-%{version}.jar
install -m 644 jsr154/dist/lib/servlet-api.jar
$RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar
+ install -m 644 libjspapi-%{version}.jar.so
$RPM_BUILD_ROOT%{_libdir}/libjspapi-%{version}.jar.so
+ install -m 644 lib%{name}-%{version}.jar.so
$RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so
+ install -m 644 jspapi-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool
-p`.d/jspapi-%{version}.db
+ install -m 644 %{name}-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool
-p`.d/%{name}-%{version}.db
(cd $RPM_BUILD_ROOT%{_javadir} && for jar in *-%{version}*; do ln -sf ${jar}
`echo $jar| sed "s|-%{version}||g"`; done)
***************
*** 94,105 ****
--- 106,125 ----
%post
update-alternatives --install %{_javadir}/servlet.jar servlet
%{_javadir}/%{name}-%{version}.jar 50
#update-alternatives --install %{_javadir}/jsp.jar jsp
%{_javadir}/jsp-api-%{version}.jar 50
+ DB=`gcj-dbtool -p`
+ rm -f $DB
+ gcj-dbtool -n $DB
+ (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
%postun
if [ "$1" = "0" ]; then
update-alternatives --remove servlet %{_javadir}/%{name}-%{version}.jar
# update-alternatives --remove jsp %{_javadir}/jsp-api-%{version}.jar
fi
+ DB=`gcj-dbtool -p`
+ rm -f $DB
+ gcj-dbtool -n $DB
+ (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
%post javadoc
rm -f %{_javadocdir}/%{name}
***************
*** 110,115 ****
--- 130,136 ----
%files
%defattr(-,root,root)
%doc LICENSE
+ %{_libdir}/*
%{_javadir}/*
%files javadoc
***************
*** 121,126 ****
--- 142,150 ----
%changelog
+ * Tue Mar 22 2005 Anthony Green <green(a)redhat.com> 0:5.0.18-1jpp_4fc
+ - Generate native libraries.
+
* Thu Nov 4 2004 Gary Benson <gbenson(a)redhat.com> 0:5.0.18-1jpp_3fc
- Build into Fedora.
4:41 p.m.
%post
update-alternatives --install %{_javadir}/servlet.jar servlet
%{_javadir}/%{name}-%{version}.jar 50
#update-alternatives --install %{_javadir}/jsp.jar jsp
%{_javadir}/jsp-api-%{version}.jar 50
+ DB=`gcj-dbtool -p`
+ rm -f $DB
+ gcj-dbtool -n $DB
+ (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
I think it was Tom who suggested we should have some structure below the
location of the db location to allow for name collisions. Will the:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
account for
$DB.d/foo/foo.jar.so
and
$DB.d/bar/bar.jar.so
and so on?
Regards
Phil
4:46 p.m.
On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote:
I think it was Tom who suggested we should have some structure below
the
location of the db location to allow for name collisions. Will the:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
account for
$DB.d/foo/foo.jar.so
and
$DB.d/bar/bar.jar.so
and so on?
No, but I think we should be using versioned names so, in theory, there
should be no collisions.
# ls -l /usr/lib/gcj-4.0.0/classmap.db.d/
total 2832
-rw-r--r-- 1 root root 1441792 Mar 22 14:19 jspapi-5.0.18.db
-rw-r--r-- 1 root root 1441792 Mar 22 14:19 servletapi5-5.0.18.db
BTW, I also think we should prefix the libs with "lib" and make them versioned.
# ls -l /usr/lib/libjspapi-5.0.18.jar.so
-rw-r--r-- 1 root root 300642 Mar 22 14:19 /usr/lib/libjspapi-5.0.18.jar.so
This will make them usable for explicit linking, and make up a little
bit for the fact that we don't have real so name versioning.
AG
5:13 p.m.
On Tue, 2005-03-22 at 14:46 -0800, Anthony Green wrote:
On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote:
> I think it was Tom who suggested we should have some structure below the
> location of the db location to allow for name collisions. Will the:
>
> (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
>
> account for
>
> $DB.d/foo/foo.jar.so
>
> and
>
> $DB.d/bar/bar.jar.so
>
> and so on?
No, but I think we should be using versioned names so, in theory, there
should be no collisions.
Okay, my example was wrong (s/jar.so/db), but I take your point. Right
now appending version is something we don't do (because we can safely
assume with our db and our location we won't have collision). Something
to keep in mind. As long as it is tied with the version of the rpm then
it should be cool. Maybe there are other issues here, but I can't think
of any.
I can't be sure but I think the merge automatically deletes the
destination "merge to" database, so there theoretically could be an
issue with the size of the argument list provided from the ls . to xargs
there. Not sure if this is something we should worry about in reality or
not
Regards
Phil
5:42 p.m.
On Tue, 2005-03-22 at 17:13 -0600, Phil Muldoon wrote:
I can't be sure but I think the merge automatically deletes the
destination "merge to" database, so there theoretically could be an
issue with the size of the argument list provided from the ls . to xargs
there. Not sure if this is something we should worry about in reality or
not
Oh, yes, you're right.
gcj-dbtool seems to create a temporary db and then copies it on top of
the real one once complete. Given that, I think this would work:
DB=`gcj-dbtool -p`
rm -f $DB
gcj-dbtool -n $DB
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[note the extra $DB on that last line]
AG
6:41 p.m.
>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
Anthony> No, but I think we should be using versioned names so, in
Anthony> theory, there should be no collisions.
The name would have to include both the package name and the jar name
in the package. It doesn't matter to me what particular naming
convention we pick, as long as it is reasonably sensible and easy to
automate... we can spell that with a '-' or a '/' :-)
The reason I opted for subdirectories is just that programs like
eclipse already use them. It presents an obvious mapping from the
.jar structure to the .so cache, and we know it cannot clash as the
original package has no clashes.
Anthony> This will make them usable for explicit linking, and make up a little
Anthony> bit for the fact that we don't have real so name versioning.
Yeah, this is attractive, at least for some of the libraries.
Tom
6:44 p.m.
>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It
Anthony> currently assumes that we should be using `gcj-dbtool -p`.
Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code.
Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o
libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar
Anthony> + gcj-dbtool -n jspapi-%{version}.db
[ ...]
If it isn't too unwieldy, I would like to see this whole section
replaced by a single call to some shell script to automate the
find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
utterly trivial...
Tom
6:55 p.m.
If it isn't too unwieldy, I would like to see this whole section
replaced by a single call to some shell script to automate the
find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
utterly trivial...
Andrew Overholt and I mused around with creating a wiki page somewhere
along the lines of "How to build your Java project with GCJ and package
it to rpm", and highlight some of the pitfalls, and strategies involved
here (that our group encountered with Eclipse). I'm not sure if Fedora
Core has a semi official wiki somewhere, but it is something I would
like to do. Also another wiki on how to debug your natively built Java
app. Hopefully that would help any Extra's project find the right path;
and make things even easier.
Regards
Phil
8:04 a.m.
On 23 Mar 2005, at 18:55, Phil Muldoon wrote:
Andrew Overholt and I mused around with creating a wiki page
somewhere
along the lines of "How to build your Java project with GCJ and
package it to rpm", and highlight some of the pitfalls, and strategies
involved here (that our group encountered with Eclipse). I'm not sure
if Fedora Core has a semi official wiki somewhere, but it is something
I would like to do. Also another wiki on how to debug your natively
built Java app. Hopefully that would help any Extra's project find the
right path; and make things even easier.
http://gcc.gnu.org/wiki/GCJ
How about this? I would be interested in your notes.
4:09 a.m.
On Wed, 2005-03-23 at 18:55 -0600, Phil Muldoon wrote:
Andrew Overholt and I mused around with creating a wiki page
somewhere
along the lines of "How to build your Java project with GCJ and package
it to rpm", and highlight some of the pitfalls, and strategies involved
here (that our group encountered with Eclipse). I'm not sure if Fedora
Core has a semi official wiki somewhere, but it is something I would
like to do. Also another wiki on how to debug your natively built Java
app. Hopefully that would help any Extra's project find the right path;
and make things even easier.
I think that would be very useful.
Maybe you could add it to http://fedoraproject.org/wiki/ ?
Thanks,
Tadej
--
Tadej Janež <tadej.janez(a)tadej.hicsalta.si>
2:29 p.m.
On Sat, 2005-03-26 at 11:09 +0100, Tadej Janež wrote:
I think that would be very useful.
Maybe you could add it to http://fedoraproject.org/wiki/ ?
Thanks,
Tadej
On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote:
http://gcc.gnu.org/wiki/GCJ
How about this? I would be interested in your notes.
Okay, when the current rush has died down, I'll write something up, and
post it to both sites.
Regards
Phil
9:41 p.m.
Phil,
If you could post here when you've done that, I'd be most appreciative.
Regards,
Dave Orme
Phil Muldoon wrote:
On Sat, 2005-03-26 at 11:09 +0100, Tadej Janež wrote:
>I think that would be very useful.
>
>Maybe you could add it to http://fedoraproject.org/wiki/ ?
>
>Thanks,
>
>Tadej
>
>
>
On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote:
>http://gcc.gnu.org/wiki/GCJ
>
>How about this? I would be interested in your notes.
>
>
Okay, when the current rush has died down, I'll write something up, and
post it to both sites.
Regards
Phil
--
fedora-devel-java-list mailing list
fedora-devel-java-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
--
Got Java? Use db4objects! <http://www.db4o.com>
PGP Public Key (for confidential communications):
http://www.coconut-palm-software.com/~djo/public_key.txt
6:58 p.m.
On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
>>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It
Anthony> currently assumes that we should be using `gcj-dbtool -p`.
Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code.
Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o
libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar
Anthony> + gcj-dbtool -n jspapi-%{version}.db
[ ...]
If it isn't too unwieldy, I would like to see this whole section
replaced by a single call to some shell script to automate the
find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
utterly trivial...
If someone sends me the script I can add it to java-1.4.2-gcj-compat.
Tom
7:25 p.m.
On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
>>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It
Anthony> currently assumes that we should be using `gcj-dbtool -p`.
Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code.
Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o
libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar
Anthony> + gcj-dbtool -n jspapi-%{version}.db
[ ...]
If it isn't too unwieldy, I would like to see this whole section
replaced by a single call to some shell script to automate the
find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
utterly trivial...
hmmm.. what do you mean by "find" in find-compile-db? I don't think
it's safe to simply compile and db-ify any .jar file in your build tree.
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
SRC_JARFILE refers to the jar file we want to process.
DEST_SO_NAME is the name we want to install it as. JPackages seem to
use different build and install jar names in some cases, so we can't
infer from SRC_JARFILE. And we should probably version the library
name.
BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS.
I suppose the script can handle certain options, like -findirect-
dispatch and -Wl,Bsymbolic.
I'm not sure I'd call this utterly trivial. Is it enough of an
improvement over what I suggested earlier?
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}`
rm -f $DB
gcj-dbtool -n $DB
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
Could these go in java-gcj-compat? Or maybe as RPM macros?
AG
12:33 p.m.
>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
> If it isn't too unwieldy, I would like to see this whole
section
> replaced by a single call to some shell script to automate the
> find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
> utterly trivial...
Anthony> hmmm.. what do you mean by "find" in find-compile-db? I
Anthony> don't think it's safe to simply compile and db-ify any .jar
Anthony> file in your build tree.
I was thinking we would do this in %install, by compiling every jar
(or war or ...) we found in the install tree. But maybe it is ugly
not to do in %build -- in which case, yeah, we need to do more
manually.
Anthony> The best we might hope for is probably something like...
Anthony> gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
Anthony> I'm not sure I'd call this utterly trivial. Is it enough of an
Anthony> improvement over what I suggested earlier?
One thing that is nice about it is we can unpack and compile war files
in the script. I suppose if we wanted we could also purge non-.class
files from jars here as well, at least until gcj gets an option to do
this.
Anthony> Then we could have another little script to replace:
Anthony> DB=`gcj-dbtool -p %{_libdir}`
Anthony> rm -f $DB
Anthony> gcj-dbtool -n $DB
Anthony> (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
Anthony> Could these go in java-gcj-compat? Or maybe as RPM macros?
Yeah, Tom F. offered to put them as scripts in java-gcj-compat. Let's
do that for the time being.
Tom
12:56 p.m.
On Fri, 2005-03-25 at 11:33 -0700, Tom Tromey wrote:
Anthony> hmmm.. what do you mean by "find" in
find-compile-db? I
Anthony> don't think it's safe to simply compile and db-ify any .jar
Anthony> file in your build tree.
I was thinking we would do this in %install, by compiling every jar
(or war or ...) we found in the install tree. But maybe it is ugly
not to do in %build -- in which case, yeah, we need to do more
manually.
I don't think we'll get much support for compiling these at install
time:
(1) as Jakub recently pointed out, it would require gcj to be installed
just to install java applications.
(2) releng types have told us that slowing down the install by compiling
things at install time is a non-starter.
AG
1:13 p.m.
>>>> "Anthony" == Anthony Green
<green(a)redhat.com> writes:
> I was thinking we would do this in %install, by compiling every
jar
> (or war or ...) we found in the install tree. But maybe it is ugly
> not to do in %build -- in which case, yeah, we need to do more
> manually.
Anthony> I don't think we'll get much support for compiling these at install
Anthony> time:
There's some terminology confusion here. As I understand RPM, which
is not much, '%install' is a step that is run while building the RPM
itself. %build does the "building", and %install puts the results
into an install tree. Then RPM uses %files to figure out how to break
down the install tree into different binary RPMs. There are other
sections you can specify if you want some script to be run when the
RPM itself is installed.
Tom
2:54 p.m.
Anthony Green writes:
On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
> >>>>> "Anthony" == Anthony Green <green(a)redhat.com>
writes:
>
> Anthony> Here's a real-world example from the servletapi5 spec file. It
> Anthony> currently assumes that we should be using `gcj-dbtool -p`.
> Anthony> Comments/suggestions welcome.
>
> Anthony> + # Generate native code.
> Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o
libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar
> Anthony> + gcj-dbtool -n jspapi-%{version}.db
> [ ...]
>
> If it isn't too unwieldy, I would like to see this whole section
> replaced by a single call to some shell script to automate the
> find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
> utterly trivial...
hmmm.. what do you mean by "find" in find-compile-db? I don't think
it's safe to simply compile and db-ify any .jar file in your build tree.
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
SRC_JARFILE refers to the jar file we want to process.
DEST_SO_NAME is the name we want to install it as. JPackages seem to
use different build and install jar names in some cases, so we can't
infer from SRC_JARFILE. And we should probably version the library
name.
BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS.
I suppose the script can handle certain options, like -findirect-
dispatch and -Wl,Bsymbolic.
I'm not sure I'd call this utterly trivial. Is it enough of an
improvement over what I suggested earlier?
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}`
rm -f $DB
I don't like this. Any process that starts during this time will fail
because the .db is missing.
The right way is to find everything and merge into the master.
This is how it should work:
DB=`gcj-dbtool -p %{_libdir}`
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
If we expect problems with command line lengths I'll fix gcj-dbtool to
take the list from stdin.
Andrew.
4:48 p.m.
* Anthony Green <green(a)redhat.com> [2005-03-24 20:30]:
> If it isn't too unwieldy, I would like to see this whole
section
> replaced by a single call to some shell script to automate the
> find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
> utterly trivial...
<snip>
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}`
rm -f $DB
gcj-dbtool -n $DB
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
How about the attached three scripts? gcj-findandnativify.sh is kinda
flaky, but it'll work well for us during the eclipse build procedure (I'm
testing a build now). I've attached a patch to the current eclipse.spec
and it simplifies things greatly. Comments welcome.
Could these go in java-gcj-compat? Or maybe as RPM macros?
Tom Fitzsimmons has offered to put these in java-gcj-compat.
Andrew
9:10 a.m.
It's been pointed out to me that if we merge db's with the obvious
(find . -name 'temp-*.db' | xargs gcj-dbtool -m $DB)
we run the risk of failure if arg length exceeds the operating system
limit, because xargs will call gcj-dbtool several times.
The right way to fix this is to have gcj-dbtool read a list of files
from stdin, which is what this patch does.
(find . -name 'temp-*.db' | gcj-dbtool - -m $DB)
Andrew.
2005-03-30 Andrew Haley <aph(a)redhat.com>
* gnu/gcj/tools/gcj_dbtool/Main.java (Fileset): New class.
(getFiles): New method.
(main): Add "-" argument.
Read list of files from stdin when merging map databases.
(usage): Add "-" argument.
Minor corrections.
Index: Main.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java,v
retrieving revision 1.9
diff -c -2 -p -r1.9 Main.java
*** Main.java 25 Mar 2005 00:38:43 -0000 1.9
--- Main.java 30 Mar 2005 15:04:15 -0000
*************** public class Main
*** 23,27 ****
--- 23,37 ----
public static void main (String[] s)
{
+ boolean fileListFromStdin = false;
insist (s.length >= 1);
+
+ if (s[0].equals("-"))
+ {
+ fileListFromStdin = true;
+ String[] newArgs = new String[s.length - 1];
+ System.arraycopy(s, 1, newArgs, 0, s.length - 1);
+ s = newArgs;
+ }
+
if (s[0].equals("-v") || s[0].equals("--version"))
{
*************** public class Main
*** 146,151 ****
{
// Merge databases.
! insist (s.length >= 3);
! try
{
File database = new File(s[1]);
--- 156,162 ----
{
// Merge databases.
! insist (s.length >= 3
! || fileListFromStdin && s.length == 2);
! try
{
File database = new File(s[1]);
*************** public class Main
*** 156,171 ****
int newSize = 0;
int newStringTableSize = 0;
! PersistentByteMap[] sourceMaps = new PersistentByteMap[s.length - 2];
// Scan all the input files, calculating worst case string
// table and hash table use.
! for (int i = 2; i < s.length; i++)
! {
! PersistentByteMap b
! = new PersistentByteMap(new File(s[i]),
! PersistentByteMap.AccessMode.READ_ONLY);
! newSize += b.size();
! newStringTableSize += b.stringTableSize();
! sourceMaps[i - 2] = b;
! }
newSize *= 1.5; // Scaling the new size by 1.5 results in
--- 167,188 ----
int newSize = 0;
int newStringTableSize = 0;
! Fileset files = getFiles(s, 2, fileListFromStdin);
! PersistentByteMap[] sourceMaps = new PersistentByteMap[files.size()];
!
// Scan all the input files, calculating worst case string
// table and hash table use.
! {
! Iterator it = files.iterator();
! int i = 0;
! while (it.hasNext())
! {
! PersistentByteMap b
! = new PersistentByteMap((File)it.next(),
! PersistentByteMap.AccessMode.READ_ONLY);
! newSize += b.size();
! newStringTableSize += b.stringTableSize();
! sourceMaps[i++] = b;
! }
! }
newSize *= 1.5; // Scaling the new size by 1.5 results in
*************** public class Main
*** 297,310 ****
+ " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map
database\n"
+ " gcj-dbtool -a file.gcjdb file.jar file.so\n"
! + " - Add the contents of file.jar to a new gcj map
database\n"
+ " gcj-dbtool -f file.gcjdb file.jar file.so\n"
! + " - Add the contents of file.jar to a new gcj map
database\n"
+ " gcj-dbtool -t file.gcjdb - Test a gcj map
database\n"
+ " gcj-dbtool -l file.gcjdb - List a gcj map
database\n"
! + " gcj-dbtool -m dest.gcjdb [source.gcjdb]...\n"
! + " - Merge gcj map databases into dest\n"
! + " Replaces dest\n"
! + " To add to dest, include dest in the list of
sources\n"
! + " gcj-dbtool -p [LIBDIR] - Print default database
name");
}
--- 314,329 ----
+ " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map
database\n"
+ " gcj-dbtool -a file.gcjdb file.jar file.so\n"
! + " - Add the contents of file.jar to a gcj map database\n"
+ " gcj-dbtool -f file.gcjdb file.jar file.so\n"
! + " - Add the contents of file.jar to a gcj map database\n"
+ " gcj-dbtool -t file.gcjdb - Test a gcj map
database\n"
+ " gcj-dbtool -l file.gcjdb - List a gcj map
database\n"
! + " gcj-dbtool [-] -m dest.gcjdb [source.gcjdb]...\n"
! + " - Merge gcj map databases into dest\n"
! + " Replaces dest\n"
! + " To add to dest, include dest in the list of
sources\n"
! + " If the first arg is -, read the list from stdin\n"
! + " gcj-dbtool -p [LIBDIR] - Print default database
name"
! );
}
*************** public class Main
*** 406,409 ****
--- 425,485 ----
return hexBytes.toString();
}
+
+
+ // Return a Fileset, either from a String array or from System.in,
+ // depending on fileListFromStdin.
+ private static final Fileset getFiles(String[] s, int startPos,
+ boolean fileListFromStdin)
+ {
+ if (fileListFromStdin)
+ return new Fileset(System.in);
+ else
+ return new Fileset(s, startPos, s.length);
+ }
}
+ // A Fileset is a container for a set of files; it can be created
+ // either from a string array or from an input stream.
+ class Fileset
+ {
+ LinkedHashSet files = new LinkedHashSet();
+
+ Fileset (String[] s, int start, int end)
+ {
+ for (int i = start; i < end; i++)
+ {
+ files.add(new File(s[i]));
+ }
+ }
+
+ Fileset (InputStream is)
+ {
+ Reader r = new BufferedReader(new InputStreamReader(is));
+ StringBuffer buf = new StringBuffer();
+ try
+ {
+ int chr;
+ while ((chr = r.read()) != -1)
+ buf.append((char)chr);
+ }
+ catch (IOException _)
+ {
+ }
+ StringTokenizer st = new StringTokenizer(buf.toString());
+ while (st.hasMoreElements ())
+ {
+ String name = st.nextToken ();
+ files.add(new File(name));
+ }
+ }
+
+ Iterator iterator()
+ {
+ return files.iterator();
+ }
+
+ int size()
+ {
+ return files.size();
+ }
+ }
10:18 p.m.
Hi,
On Tue, 2005-03-29 at 17:48 -0500, Andrew Overholt wrote:
> Could these go in java-gcj-compat? Or maybe as RPM macros?
Tom Fitzsimmons has offered to put these in java-gcj-compat.
These scripts are in java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. I
renamed them find-and-nativify, nativify and rename-gcj-db.
Tom
8:36 p.m.
* Andrew Overholt <overholt(a)redhat.com> [2005-03-29 16:52]:
[...]
> (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[...]
I'm thinking this should be:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
What's the purpose of the extraneous $DB? I don't think we want it because
we actually want the entire db recreated every time. We don't want entries
that are not in sub-dbs in $DB.d to be in the resultant db. Does that make
sense?
Andrew
10:43 p.m.
On Mon, 2005-04-04 at 21:36 -0400, Andrew Overholt wrote:
* Andrew Overholt <overholt(a)redhat.com> [2005-03-29 16:52]:
[...]
> > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[...]
I'm thinking this should be:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
What's the purpose of the extraneous $DB? I don't think we want it because
we actually want the entire db recreated every time. We don't want entries
that are not in sub-dbs in $DB.d to be in the resultant db. Does that make
sense?
The -m option cases the destination database to be overwritten. If you
want to maintain its contents you need to specify it as a source
database. From "gcj-dbtool --help" output:
gcj-dbtool -m dest.gcjdb [source.gcjdb]...
- Merge gcj map databases into dest
Replaces dest
To add to dest, include dest in the list of sources
But as I understand it, rebuild-gcj-db is supposed to rebuild
classmap.db from scratch. If that's the intended behaviour (and is safe
-- aph?) then
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
is correct.
Tom
3:38 a.m.
Andrew Overholt writes:
* Andrew Overholt <overholt(a)redhat.com> [2005-03-29 16:52]:
[...]
> > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[...]
I'm thinking this should be:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
What's the purpose of the extraneous $DB? I don't think we want it because
we actually want the entire db recreated every time. We don't want entries
that are not in sub-dbs in $DB.d to be in the resultant db. Does that make
sense?
Yes. The extra $DB is there because xargs will call gcj-dbtool
multiple times if it needs to. The right answer is not to use xargs.
Andrew.
6959
days inactive
6973
days old
java-devel@lists.fedoraproject.org
47 comments
10 participants
participants (10)
-
Andrew Haley -
Andrew Overholt -
Anthony Green -
David J. Orme -
Jakub Jelinek -
Phil Muldoon -
Phil Shaw -
Tadej Janež -
Thomas Fitzsimmons -
Tom Tromey