10:40 a.m.
Over the past couple of days I've been writing a replacement for
aot-compile and find-and-aot-compile. They were both good when they
were first written but the demands of Eclipse and JOnAS have exposed
numerous shortcomings.
Attached is a copy of aot-compile-rpm which I'd like to commit into
java-1.4.2-gcj-compat if everyone's agreeable. It's an order of
magnitude more complex than aot-compile and find-and-aot-compile, but
it's advantages over them are manifold:
IT'S MUCH MORE USABLE
=====================
Nativifying an rpm using aot-compile-rpm is a matter of
copy-and-paste:
1. Remove "BuildArch: noarch"
2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp"
and "Requires(post,postun)" on same.
3. Add "aot-compile-rpm" to the very end of %install.
4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun.
5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
With aot-compile or find-and-aot-compile step 4 was much more
complex. I was always uneasy about nativifying things I didn't
myself maintain, postgresql-jdbc for example, because I was wary of
dropping a bunch of fragile code on someone else. No longer.
IT FINDS JARS BY SIGNATURE RATHER THAN BY EXTENSION
===================================================
find-and-aot-compile identifies jarfiles by their extension, ".jar",
so it misses ".war", ".ear", ".rar", and anything else the
Java
world happens to invent. aot-compile-rpm identifies jarfiles by
opening them, so it catches them no matter what they're called.
It's already found some unexpected stuff. Tomcat, for example, has
a couple of servlets that are disabled by default because they are
in jarfiles called ".renametojar". aot-compile-rpm finds and
compiles these, so if the user renames them to enable the servlets
then they'll be running BC-compiled code.
IT IGNORES SUBSETTED JARFILES
=============================
Several packages contain jarfiles which are a subset of others.
MX4J, for example, has the APIs in mx4j-jmx.jar, the implementation
in mx4j-impl.jar, and both together in mx4j.jar. aot-compile-rpm
recognises that compiling mx4j.jar will get every class in the other
two jars too, so it'll only compile mx4j.jar. So, aot-compile-rpm
compiles MX4J in half the time (and generates half the bytes) that
find-and-aot-compile does.
IT WORKS AROUND THE PPC GO2 LIMIT
=================================
PPC machines are limited on the size of jarfiles that can be
compiled in one go, affecting Eclipse and JacORB, as described
at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
aot-compile-rpm splits large jarfiles on ppc to avoid this.
One limitation of aot-compile and find-and-aot-compile that I have not
addressed (yet) is SMP support. Andrew Overholt suggested generating
a Makefile and letting make handle the complex stuff, which I think is
an excellent idea. Implementing something along those lines is
something I'd like to do, but I need to get ppc64 and s390*
bootstrapped first.
Cheers,
Gary
11:51 a.m.
Hi,
On Wed, 2005-07-06 at 16:40 +0100, Gary Benson wrote:
Over the past couple of days I've been writing a replacement for
aot-compile and find-and-aot-compile. They were both good when they
were first written but the demands of Eclipse and JOnAS have exposed
numerous shortcomings.
Attached is a copy of aot-compile-rpm which I'd like to commit into
java-1.4.2-gcj-compat if everyone's agreeable. It's an order of
magnitude more complex than aot-compile and find-and-aot-compile, but
it's advantages over them are manifold:
IT'S MUCH MORE USABLE
=====================
Nativifying an rpm using aot-compile-rpm is a matter of
copy-and-paste:
1. Remove "BuildArch: noarch"
2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp"
and "Requires(post,postun)" on same.
Releng told me to separate these requires:
Requires(post):
and
Requires(postun):
because certain versions of RPM fail on the (post,postun) syntax.
3. Add "aot-compile-rpm" to the very end of %install.
4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun.
5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
With aot-compile or find-and-aot-compile step 4 was much more
complex. I was always uneasy about nativifying things I didn't
myself maintain, postgresql-jdbc for example, because I was wary of
dropping a bunch of fragile code on someone else. No longer.
IT FINDS JARS BY SIGNATURE RATHER THAN BY EXTENSION
===================================================
find-and-aot-compile identifies jarfiles by their extension, ".jar",
so it misses ".war", ".ear", ".rar", and anything else
the Java
world happens to invent. aot-compile-rpm identifies jarfiles by
opening them, so it catches them no matter what they're called.
It's already found some unexpected stuff. Tomcat, for example, has
a couple of servlets that are disabled by default because they are
in jarfiles called ".renametojar". aot-compile-rpm finds and
compiles these, so if the user renames them to enable the servlets
then they'll be running BC-compiled code.
Does aot-compile-rpm provide a way to exclude certain jars from native
compilation? This is sometimes necessary to work around gcj bugs.
IT IGNORES SUBSETTED JARFILES
=============================
Several packages contain jarfiles which are a subset of others.
MX4J, for example, has the APIs in mx4j-jmx.jar, the implementation
in mx4j-impl.jar, and both together in mx4j.jar. aot-compile-rpm
recognises that compiling mx4j.jar will get every class in the other
two jars too, so it'll only compile mx4j.jar. So, aot-compile-rpm
compiles MX4J in half the time (and generates half the bytes) that
find-and-aot-compile does.
IT WORKS AROUND THE PPC GO2 LIMIT
=================================
PPC machines are limited on the size of jarfiles that can be
compiled in one go, affecting Eclipse and JacORB, as described
at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
aot-compile-rpm splits large jarfiles on ppc to avoid this.
One limitation of aot-compile and find-and-aot-compile that I have not
addressed (yet) is SMP support. Andrew Overholt suggested generating
a Makefile and letting make handle the complex stuff, which I think is
an excellent idea. Implementing something along those lines is
something I'd like to do, but I need to get ppc64 and s390*
bootstrapped first.
Great! This will be excellent.
Tom
12:10 p.m.
Thomas Fitzsimmons wrote:
On Wed, 2005-07-06 at 16:40 +0100, Gary Benson wrote:
> 2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp"
> and "Requires(post,postun)" on same.
Releng told me to separate these requires:
Requires(post):
and
Requires(postun):
because certain versions of RPM fail on the (post,postun) syntax.
I've seen bugs from it before, but I didn't know they worked
separately. Cool...
> aot-compile-rpm identifies jarfiles by opening them, so it
> catches them no matter what they're called.
Does aot-compile-rpm provide a way to exclude certain jars from
native compilation? This is sometimes necessary to work around gcj
bugs.
There's no generic way, but if you have already compiled a solib
yourself then it won't recreate it. This allows you to compile it
with -O0 instead of -O2, for example, which has worked for every gcj
bug I've seen so far.
Cheers,
Gary
12:48 p.m.
On Wed, 2005-06-07 at 18:10 +0100, Gary Benson wrote:
Thomas Fitzsimmons wrote:
> Does aot-compile-rpm provide a way to exclude certain jars from
> native compilation? This is sometimes necessary to work around gcj
> bugs.
There's no generic way, but if you have already compiled a solib
yourself then it won't recreate it. This allows you to compile it
with -O0 instead of -O2, for example, which has worked for every gcj
bug I've seen so far.
The way we've been doing it with Eclipse is by moving the .jars that we
don't want to be compiled to .jar.bak. This won't work with
aot-compile-rpm, so we'll have to find a better way. -O2 -> -O0 doesn't
work in some cases. Yes, tracking down the remaining mis-compilations
is on my list of things to do :) .
Andrew
6:25 a.m.
Andrew Overholt wrote:
On Wed, 2005-06-07 at 18:10 +0100, Gary Benson wrote:
> Thomas Fitzsimmons wrote:
> > Does aot-compile-rpm provide a way to exclude certain jars from
> > native compilation? This is sometimes necessary to work around
> > gcj bugs.
>
> There's no generic way, but if you have already compiled a solib
> yourself then it won't recreate it. This allows you to compile it
> with -O0 instead of -O2, for example, which has worked for every
> gcj bug I've seen so far.
The way we've been doing it with Eclipse is by moving the .jars that
we don't want to be compiled to .jar.bak. This won't work with
aot-compile-rpm, so we'll have to find a better way. -O2 -> -O0
doesn't work in some cases. Yes, tracking down the remaining
mis-compilations is on my list of things to do :) .
Ok, I added an --exclude option to handle this, and it's now built in
beehive as java-1.4.2-gcj-compat-1.4.2.0-40jpp_32rh so if you could
test it it would be very cool. You should be able to drop all solib
compilation and database building stuff, sticking an aot-compile-rpm
at the end of %install, and changing the %files sections to the new
locations.
Note that for --exclude the path you must is the final installed
path of the jarfile, for example
/usr/share/eclipse/plugins/org.eclipse.ui.workbench_3.1.0.jar
(_not_ prefixed with $RPM_BUILD_ROOT).
Note also that you shouldn't need to do this for the PPC limit
(#158308) because aot-compile-rpm ought to be able to handle it.
If you do have problems then let me know as it's a bug I should
be fixing.
Also note that for optimizer failures you can build the solib
yourself into the location that aot-compile-rpm would have built
it _before_ running aot-compile-rpm. aot-compile-rpm will generate
the database for it.
Finally, note that you can remove the %{_libdir} argument from all
the rebuild-gcj-db commands, as it's not necessary any more.
Cheers,
Gary
4:16 a.m.
The new rebuild-gcj-db will fail (I think) if the full list of .db files
cannot fit on one Linux command line. The following patch, which I just
tested, fixes this:
--- rebuild-gcj-db.orig 2005-07-09 10:07:00.000000000 +0100
+++ rebuild-gcj-db 2005-07-09 10:07:19.000000000 +0100
@@ -17,4 +17,4 @@
dirname $dbLocation | xargs mkdir -p
/usr/bin/gcj-dbtool -n $dbLocation 64
find $dbLocation.d /usr/lib/gcj -name '*.db' -print0 | \
- xargs -0 /usr/bin/gcj-dbtool -m $dbLocation $dbLocation
+ /usr/bin/gcj-dbtool -0 -m $dbLocation $dbLocation
5:03 a.m.
Robin Green writes:
The new rebuild-gcj-db will fail (I think) if the full list of .db
files cannot fit on one Linux command line.
Are you sure that it will fail? I'm quite happy to belive you if
you've really tried it, but I see nothing incorrect about the script.
Your patch is nore efficient, however, so it's probably worth doing
just because of that.
The following patch, which I just tested, fixes this:
--- rebuild-gcj-db.orig 2005-07-09 10:07:00.000000000 +0100
+++ rebuild-gcj-db 2005-07-09 10:07:19.000000000 +0100
@@ -17,4 +17,4 @@
dirname $dbLocation | xargs mkdir -p
/usr/bin/gcj-dbtool -n $dbLocation 64
find $dbLocation.d /usr/lib/gcj -name '*.db' -print0 | \
- xargs -0 /usr/bin/gcj-dbtool -m $dbLocation $dbLocation
+ /usr/bin/gcj-dbtool -0 -m $dbLocation $dbLocation
Should be just
+ /usr/bin/gcj-dbtool -0 -m $dbLocation
I think.
Andrew.
12:50 p.m.
On Mon, 11 Jul 2005 11:03:26 +0100, Andrew Haley wrote:
Robin Green writes:
> The new rebuild-gcj-db will fail (I think) if the full list of .db
> files cannot fit on one Linux command line.
Are you sure that it will fail?
No - actually, I was wrong. I missed the fact that the double $dbLocation
would make it work.
9:06 a.m.
On Wed, 06 Jul 2005 18:10:26 +0100, Gary Benson wrote:
There's no generic way, but if you have already compiled a solib
yourself then it won't recreate it. This allows you to compile it
with -O0 instead of -O2, for example, which has worked for every gcj
bug I've seen so far.
By the way - if you compile with -O0, find-debuginfo.sh fails to find
the source code, so you end up with missing source code in the -debuginfo
package. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161722
where I've supplied a fix.
This may be a moot point at the moment however, because some
Java -debuginfo packages don't have any source code anyway, for another
reason - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153247
Obviously both are low-priority bugs at best, because you can just get the
source code from the corresponding .src.rpm, rpmbuild -bp foo.spec to
apply any patches, and then optionally shove it where the debugger can
find it, which should work in 99% of cases, but I thought I'd mention them
anyway.
--
Robin
11:33 a.m.
Robin Green wrote:
Obviously both are low-priority bugs at best, because you can just
get the source code from the corresponding .src.rpm, rpmbuild -bp
foo.spec to apply any patches, and then optionally shove it where
the debugger can find it, which should work in 99% of cases, but I
thought I'd mention them anyway.
Thanks :)
2:28 p.m.
On Wed, 06 Jul 2005 16:40:56 +0100, Gary Benson wrote:
Over the past couple of days I've been writing a replacement for
aot-compile and find-and-aot-compile.
Good stuff, looking forward to using it! I've attached a matching
rebuild-gcj-db2 script and a sample Hello World .spec so that others can
more easily try it out.
Is it worth merging the .db files into one .db file per package, to
reduce the number of files that have to be merged at RPM install time?
--
Robin
3:35 a.m.
Robin Green wrote:
Is it worth merging the .db files into one .db file per package, to
reduce the number of files that have to be merged at RPM install
time?
One big database doesn't work with packages that have more than one
binary rpm containing jarfiles. The optimum would really be one
database per binary rpm, but there's no way to get that information
at a time you can make use of it.
Cheers,
Gary
11:08 a.m.
>>>> "Gary" == Gary Benson
<gbenson(a)redhat.com> writes:
Gary> IT WORKS AROUND THE PPC GO2 LIMIT
Gary> =================================
Gary> PPC machines are limited on the size of jarfiles that can be
Gary> compiled in one go, affecting Eclipse and JacORB, as described
Gary> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
Gary> aot-compile-rpm splits large jarfiles on ppc to avoid this.
Gary> """In order to avoid #158308 we must split large jarfiles on
PPC."""
Gary> if os.environ.get("RPM_ARCH") != "ppc":
Gary> return [src.filename]
You may want to do the splitting unconditionally. Then we won't
generate machine-crushing gigabyte .s files anywhere, and we will be
able to remove property files and other unused bits from the jars on
all platforms.
Tom
11:17 a.m.
Tom Tromey wrote:
>>>>> "Gary" == Gary Benson
<gbenson(a)redhat.com> writes:
Gary> IT WORKS AROUND THE PPC GO2 LIMIT
Gary> =================================
Gary> PPC machines are limited on the size of jarfiles that can be
Gary> compiled in one go, affecting Eclipse and JacORB, as described
Gary> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
Gary> aot-compile-rpm splits large jarfiles on ppc to avoid this.
Gary> """In order to avoid #158308 we must split large jarfiles on
PPC."""
Gary> if os.environ.get("RPM_ARCH") != "ppc":
Gary> return [src.filename]
You may want to do the splitting unconditionally. Then we won't
generate machine-crushing gigabyte .s files anywhere, and we will be
able to remove property files and other unused bits from the jars on
all platforms.
Since my machine has been in swapstorms over eclipse all afternoon I'm
inclined to agree with you.
When we compile, then nothing except classes are touched?
Cheers,
Gary
11:19 a.m.
Gary Benson writes:
Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson <gbenson(a)redhat.com>
writes:
>
> Gary> IT WORKS AROUND THE PPC GO2 LIMIT
> Gary> =================================
> Gary> PPC machines are limited on the size of jarfiles that can be
> Gary> compiled in one go, affecting Eclipse and JacORB, as described
> Gary> at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
> Gary> aot-compile-rpm splits large jarfiles on ppc to avoid this.
>
> Gary> """In order to avoid #158308 we must split large
jarfiles on PPC."""
> Gary> if os.environ.get("RPM_ARCH") != "ppc":
> Gary> return [src.filename]
>
> You may want to do the splitting unconditionally. Then we won't
> generate machine-crushing gigabyte .s files anywhere, and we will be
> able to remove property files and other unused bits from the jars on
> all platforms.
Since my machine has been in swapstorms over eclipse all afternoon I'm
inclined to agree with you.
When we compile, then nothing except classes are touched?
Nothing except classes are used, no.
Andrew.
11:32 a.m.
Andrew Haley wrote:
Gary Benson wrote:
> When we compile, then nothing except classes are touched?
Nothing except classes are used, no.
Cool, that's something I've been meaning to ask. I know it wasn't
always like that, but I thought it might have changed with BC ABI.
Cheers,
Gary
11:35 a.m.
Gary Benson writes:
Andrew Haley wrote:
> Gary Benson wrote:
> > When we compile, then nothing except classes are touched?
>
> Nothing except classes are used, no.
Cool, that's something I've been meaning to ask. I know it wasn't
always like that, but I thought it might have changed with BC ABI.
It hansn't, not really. It's just that when we have the jar files
around anyway there's no point diverting accesses to resources in the
jars into the binary files.
Andrew.
11:36 a.m.
Andrew Haley wrote:
Gary Benson writes:
> Andrew Haley wrote:
> > Gary Benson wrote:
> > > When we compile, then nothing except classes are touched?
> >
> > Nothing except classes are used, no.
>
> Cool, that's something I've been meaning to ask. I know it wasn't
> always like that, but I thought it might have changed with BC ABI.
It hansn't, not really. It's just that when we have the jar files
around anyway there's no point diverting accesses to resources in
the jars into the binary files.
Yeah.
Cheers,
Gary
10:25 a.m.
Hi Gary,
This is great!
* Gary Benson <gbenson(a)redhat.com> [2005-07-06 11:41]:
5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
I've chopped down the Eclipse specfile and changed it to use your new
aot-compile, but the files section is confusing to me. With Eclipse, we
split up the package into sub-RPMs. Can we make it so that the native bits
are split up like this? Should I just go through and change my current
%{_libdir}/%{name}/<blah> to %{_libdir}/gcj/%{name}/<blah> in each of the
sub-packages' %files sections?
Thanks for doing this,
Andrew
5:06 a.m.
Andrew Overholt wrote:
* Gary Benson <gbenson(a)redhat.com> [2005-07-06 11:41]:
>
> 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
I've chopped down the Eclipse specfile and changed it to use
your
new aot-compile, but the files section is confusing to me. With
Eclipse, we split up the package into sub-RPMs. Can we make it so
that the native bits are split up like this?
Unfortunatly no, not automatically. The information is not made
available by rpm. There are two options:
Should I just go through and change my current
%{_libdir}/%{name}/<blah> to %{_libdir}/gcj/%{name}/<blah> in each
of the sub-packages' %files sections?
This is one option. The other is to rearrange the files after the
aot-compile-rpm line in %install. The one you suggested is probably
better.
Cheers,
Gary
7:38 a.m.
* Gary Benson <gbenson(a)redhat.com> [2005-07-13 06:06]:
Andrew Overholt wrote:
> * Gary Benson <gbenson(a)redhat.com> [2005-07-06 11:41]:
> >
> > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
>
> I've chopped down the Eclipse specfile and changed it to use your
> new aot-compile, but the files section is confusing to me. With
> Eclipse, we split up the package into sub-RPMs. Can we make it so
> that the native bits are split up like this?
Unfortunatly no, not automatically. The information is not made
available by rpm. There are two options:
> Should I just go through and change my current
> %{_libdir}/%{name}/<blah> to %{_libdir}/gcj/%{name}/<blah> in each
> of the sub-packages' %files sections?
This is one option. The other is to rearrange the files after the
aot-compile-rpm line in %install. The one you suggested is probably
better.
Okay, but what about the .db? Right now we have multiple dbs - one for
each sub-package. Can we have this as well?
Thanks,
Andrew
8:28 a.m.
Andrew Overholt wrote:
* Gary Benson <gbenson(a)redhat.com> [2005-07-13 06:06]:
> Andrew Overholt wrote:
> > * Gary Benson <gbenson(a)redhat.com> [2005-07-06 11:41]:
> > > 5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
>
> > I've chopped down the Eclipse specfile and changed it to use
> > your new aot-compile, but the files section is confusing to me.
> > With Eclipse, we split up the package into sub-RPMs. Can we
> > make it so that the native bits are split up like this?
>
> Unfortunatly no, not automatically. The information is not made
> available by rpm. There are two options:
> [snip]
Okay, but what about the .db? Right now we have multiple dbs - one
for each sub-package. Can we have this as well?
aot-compile-rpm will make a separate database for each jarfile.
Cheers,
Gary
1:48 p.m.
* Gary Benson <gbenson(a)redhat.com> [2005-07-13 09:28]:
> Okay, but what about the .db? Right now we have multiple dbs -
one
> for each sub-package. Can we have this as well?
aot-compile-rpm will make a separate database for each jarfile.
Cool. I went through and added aot-compile-rpm to the end of %install but
it fails with:
+ aot-compile-rpm
Traceback (most recent call last):
File "/usr/bin/aot-compile-rpm", line 203, in ?
aot_compile_rpm(
File "/usr/bin/aot-compile-rpm", line 25, in aot_compile_rpm
for jar in weed_jars(strip_exclusions(find_jars(basedir), exclusions)):
File "/usr/bin/aot-compile-rpm", line 48, in find_jars
os.path.walk(dir, visit, jars)
File "/usr/lib/python2.4/posixpath.py", line 298, in walk
walk(name, func, arg)
File "/usr/lib/python2.4/posixpath.py", line 298, in walk
walk(name, func, arg)
File "/usr/lib/python2.4/posixpath.py", line 298, in walk
walk(name, func, arg)
File "/usr/lib/python2.4/posixpath.py", line 298, in walk
walk(name, func, arg)
File "/usr/lib/python2.4/posixpath.py", line 298, in walk
walk(name, func, arg)
File "/usr/lib/python2.4/posixpath.py", line 290, in walk
func(arg, top, names)
File "/usr/bin/aot-compile-rpm", line 45, in visit
assert not jars.has_key(item)
AssertionError
error: Bad exit status from /var/tmp/rpm-tmp.84677 (%install)
Any ideas? My python-fu is _very_ weak (and by that I mean it's
non-existent).
Andrew
3:54 a.m.
Andrew Overholt wrote:
Cool. I went through and added aot-compile-rpm to the end of
%install but it fails with:
+ aot-compile-rpm
Traceback (most recent call last):
[snip]
AssertionError
error: Bad exit status from /var/tmp/rpm-tmp.84677 (%install)
Any ideas? My python-fu is _very_ weak (and by that I mean it's
non-existent).
I committed some improvements to this bit yesterday; the very latest
aot-compile-rpm (from java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_37rh)
might cope, and even if it doesn't it'll give you a more meaningful
error message.
(And if it does give an error then let me know and I'll fix it...)
Cheers,
Gary
4:09 a.m.
Gary Benson wrote:
Andrew Overholt wrote:
> Cool. I went through and added aot-compile-rpm to the end of
> %install but it fails with:
>
> + aot-compile-rpm
> Traceback (most recent call last):
> [snip]
> AssertionError
> error: Bad exit status from /var/tmp/rpm-tmp.84677 (%install)
>
> Any ideas? My python-fu is _very_ weak (and by that I mean it's
> non-existent).
I committed some improvements to this bit yesterday; the very latest
aot-compile-rpm (from java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_37rh)
might cope, and even if it doesn't it'll give you a more meaningful
error message.
I guess it coped then ;)
Can I suggest this patch to eclipse.spec?
Cheers,
Gary
7:47 a.m.
* Gary Benson <gbenson(a)redhat.com> [2005-07-15 05:09]:
I guess it coped then ;)
Yup!
Can I suggest this patch to eclipse.spec?
[...]
+aot-compile-rpm \
+ --exclude /usr/share/eclipse/plugins/org.eclipse.ui.forms_3.1.0.jar \
+ --exclude /usr/share/eclipse/plugins/org.eclipse.ui.workbench_3.1.0.jar \
+ --exclude /usr/share/eclipse/plugins/org.eclipse.osgi_3.1.0.jar
I tried the multiple --excludes and it didn't work. I assumed that syntax
was just not supported. It is actually better IMO if we leave the jar.sos
around (I should have made them .bak) so that it's easy to test if they're
still mis-compiled.
Either way, the new aot-compile-rpm is amAzing and I'm in the process or
enabling it in all the other packages for which I am responsible. Thanks!
Andrew
8:35 a.m.
Andrew Overholt wrote:
I tried the multiple --excludes and it didn't work. I assumed
that
syntax was just not supported.
It should be, must be a bug. If it's not bothering you I'll not fix
it right away, as I'm busy bootstrapping stuff onto the missing archs
(and switching all my stuff to aot-compile-rpm as I go).
Either way, the new aot-compile-rpm is amAzing and I'm in the
process or enabling it in all the other packages for which I am
responsible. Thanks!
You're welcome!
Oh, and I'll do jsch, because I need it like now.
Cheers,
Gary
8:51 a.m.
* Gary Benson <gbenson(a)redhat.com> [2005-07-15 09:35]:
Andrew Overholt wrote:
> I tried the multiple --excludes and it didn't work. I assumed that
> syntax was just not supported.
It should be, must be a bug. If it's not bothering you I'll not fix
it right away, as I'm busy bootstrapping stuff onto the missing archs
(and switching all my stuff to aot-compile-rpm as I go).
Sure, sounds good.
Oh, and I'll do jsch, because I need it like now.
Oh yeah, sorry.
Andrew
9:25 a.m.
New subject: aot-compile-rpm HOWTO
A quick update on the aot-compile-rpm instructions...
Gary Benson wrote:
1. Remove "BuildArch: noarch"
2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp"
and "Requires(post,postun)" on same.
The actual lines required for this step are:
BuildRequires: java-gcj-compat-devel >= 1.0.31
Requires(post): java-gcj-compat >= 1.0.31
Requires(postun): java-gcj-compat >= 1.0.31
If your package is jonas or eclipse then the first line should say
1.0.33 instead of 1.0.31.
3. Add "aot-compile-rpm" to the very end of %install.
4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun.
This should be:
Add "%{_bindir}/rebuild-gcj-db" to %post and %postun.
Note the lack of %{_libdir}!
5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to
%files.
6860
days inactive
6869
days old
java-devel@lists.fedoraproject.org
29 comments
6 participants
participants (6)
-
Andrew Haley -
Andrew Overholt -
Gary Benson -
Robin Green -
Thomas Fitzsimmons -
Tom Tromey