Eclipse and Tomcat - where?
by Dan Thurman
Hi Folks,
I finally am ready to test by application on Fedora using Eclipse
and I am at the point where I am trying to run my web-application
using Tomcat.
Of course, the Tomcat dialog box pops up and asks where the
Tomcat installation directory is.... ugh.... I have NO CLUE!
On windows, Tomcat is installed by Eclipse so I dont have to
figure this out.... but on Fedora, seems like I do.
Can someone tell me what to do?
Thanks!
Dan
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005
18 years, 4 months
RFC: peephole vs RTX_FRAME_RELATED_P
by Andrew Haley
On i386 we replace (add sp -4) with (push reg). This generates faster
and smaller code.
However, we are not copying RTX_FRAME_RELATED_P from the old
instructions to the new, and so we are not emitting unwind information
for the stack pointer adjustment. The breaks stack traces on gcj, and
I suspect it breaks a bunch of stuff elsewhere too.
This very crude patch sets RTX_FRAME_RELATED_P on every one of the new
instructions if any of the old instructions had RTX_FRAME_RELATED_P
set. It seems to do the trick, but I suspect there must be a more
subtle way to do it.
Can anyone suggest a neater way to do this?
Without this patch, for
java.lang.Throwable.Throwable(java.lang.String) we get
00a326a8 <java.lang.Throwable.Throwable(java.lang.String)>:
a326a8: 56 push %esi
a326a9: 53 push %ebx
a326aa: 50 push %eax <=== ** This is the insn generated by peephole **
a326ab: e8 00 00 00 00 call a326b0 <java.lang.Throwable.Throwable(java.lang.String)+0x8>
a326b0: 5b pop %ebx
00058f08 0000001c 0003252c FDE cie=000269e0 pc=00a328f8..00a3292e
Augmentation data: 00 00 00 00
DW_CFA_advance_loc: 1 to 00a328f9
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 1 to 00a328fa
DW_CFA_def_cfa_offset: 12
DW_CFA_offset: r3 at cfa-12
DW_CFA_offset: r6 at cfa-8
DW_CFA_nop
after the patch, we get
0005946c 00000020 000328e4 FDE cie=00026b8c pc=00a326a8..00a326de
Augmentation data: 00 00 00 00
DW_CFA_advance_loc: 1 to 00a326a9
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 1 to 00a326aa
DW_CFA_def_cfa_offset: 12
DW_CFA_advance_loc: 1 to 00a326ab
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r0 at cfa-16
DW_CFA_offset: r3 at cfa-12
DW_CFA_offset: r6 at cfa-8
Here's a trivial test case:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, World!");
new Throwable().printStackTrace();
}
}
$ ~/gcc/install/bin/gcj Hello.java --main=Hello -g
$ LD_LIBRARY_PATH=~/gcc/install/lib ./a.out
Hello, World!
java.lang.Throwable
at Hello.main (Hello.java:5)
Andrew.
2005-12-19 Andrew Haley <aph(a)redhat.com>
* recog.c (peephole2_optimize): Copy RTX_FRAME_RELATED_P from old
instructions to new instructions.
Index: recog.c
===================================================================
--- recog.c (revision 108424)
+++ recog.c (working copy)
@@ -3107,6 +3107,7 @@
int match_len;
rtx note;
bool was_call = false;
+ bool frame_related = false;
/* Record this insn. */
if (--peep2_current < 0)
@@ -3122,6 +3123,14 @@
try = peephole2_insns (PATTERN (insn), insn, &match_len);
if (try != NULL)
{
+ {
+ rtx old_insn = insn;
+ for (i = 0; i <= match_len; ++i)
+ {
+ frame_related |= RTX_FRAME_RELATED_P (old_insn);
+ old_insn = NEXT_INSN (old_insn);
+ }
+ }
/* If we are splitting a CALL_INSN, look for the CALL_INSN
in SEQ and copy our CALL_INSN_FUNCTION_USAGE and other
cfg-related call notes. */
@@ -3179,6 +3188,16 @@
break;
}
+ if (frame_related)
+ {
+ rtx new_insn = try;
+ while (new_insn != NULL_RTX)
+ {
+ RTX_FRAME_RELATED_P (new_insn) = true;
+ new_insn = NEXT_INSN (new_insn);
+ }
+ }
+
i = match_len + peep2_current;
if (i >= MAX_INSNS_PER_PEEP2 + 1)
i -= MAX_INSNS_PER_PEEP2 + 1;
18 years, 4 months
Re: [fedora-java] rawhide issues
by Andrew Haley
Jakub Jelinek writes:
> On Mon, Dec 19, 2005 at 04:34:33PM +0000, Andrew Haley wrote:
> > Looking further, I realize that my analysis is quite wrong. The "push
> > %eax" is promptly followed by "pop %ebx", so a CFA offset of 12 is
> > correct. D'oh!
> >
> > This is what comes of doing my thinking in public... Still, I have
> > discovered this problem is tune=i386 specific. I'll continue looking.
> >
> >
> > 00a326a8 <java.lang.Throwable.Throwable(java.lang.String)>:
> > a326a8: 56 push %esi
> > a326a9: 53 push %ebx
> > a326aa: 50 push %eax
> > a326ab: e8 00 00 00 00 call a326b0 <java.lang.Throwable.Throwable(java.lang.String)+0x8>
> > a326b0: 5b pop %ebx
>
> Well, call here does the push and pop %ebx pops it. So this sequence
> still decreases %esp by 12 bytes.
Yeah -- I was right first time. I think I'm going to keep quiet 'til
I've solved the problem! :-)
Andrew.
18 years, 4 months
rawhide issues
by Anthony Green
I see the following issues with rawhide (on x86) right now...
* I'm not getting any stack traces, just <<No stacktrace available>>
* Eclipse fails and the log contains the following errors (with no
stacktraces):
java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context: org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION
java.lang.Exception: Cannot initialize Update Configurator
java.lang.IllegalStateException: Bundle initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active.
* aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC 4.1. I can't see where this comes from.
Any ideas?
AG
18 years, 4 months
Default Java on Linux
by David Walluck
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I just wanted to bring everyone's attention to Sun bug #6211006 (Default
Java of Linux)
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6211006>. The
initial bug was posted about a year ago, but a comment was added as
recently as 7 months ago.
I am not sure if some of these statements are lies or just genuine
misunderstandings from the developers. For example, in the comments for
bug #4680244 (RPM does not follow LSB or filesystem hierachy (sic))
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4680244>, it seems
clear that the issue is just being avoided (successfully, for over 2
years now). However, in the comments for the more recent bug, there
appears to be some possible genuine misunderstandings of RPM and Linux.
For example, is the bug author not aware that you can create multiple
packages from the same spec file, that you can include documentation
inline, that you can avoid multi-line macros by calling a script...? In
any case, the comment about update-alternatives (missing on Suse) is in
fact wrong.
Because rpms are not provided for Mustang yet as far as I know, I guess
there is no way to even find out how this bug can be marked as closed.
My main issue for writing is that bug #4680244 refers people to #6211006
(now closed). But #4680244 has been a top 25 RFE for a long time
(currently it is the #5 most-wanted RFE). I fear, based on the comments
for bug #6211006, that nothing has changed, and now it will only draw
attention away from the JPackage RFE. What's more, the idea of
``forcing'' the most recent jdk to be default is actually a step back,
that is, if I understand correctly. Despite the quoting of some RPM
documentation, the description of the actual proposed solution is left
vague, presumably because whatever they do will not be made public/open.
- --
Sincerely,
David Walluck
<david(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDo6XkarJDwJ6gwowRAiTAAJ0fksl8B7iEREyc7iQxmK2Ny7BzTwCfYtCk
Ldgev8IdRrg00EePxxbPL8s=
=3JUo
-----END PGP SIGNATURE-----
18 years, 4 months
still missing /usr/bin/rebuild-gcj-db
by John W. Himpel
All,
I am missing this file. The archives mention:
java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh
java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh
Those are installed.
Here are my "java" rpms
# rpm -qa | fgrep java
struts11-javadoc-1.1-1jpp_7fc
jakarta-taglibs-standard-javadoc-1.1.1-4jpp_1fc.1.1
java-1.5.0-sun-1.5.0.04-1jpp
java-1.5.0-sun-devel-1.5.0.04-1jpp
javacc-3.2-1jpp_3fc
ant-javamail-1.6.2-3jpp_14fc
gcc-java-4.0.2-8.fc4
struts-javadoc-1.2.4-2jpp_3fc
java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh
java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh
java-1.5.0-sun-plugin-1.5.0.04-1jpp
jakarta-taglibs-standard-javadoc-1.1.1-4jpp_1fc
ant-javamail-1.6.5-0jpp_1fc
Is there a workaround or fix?
Thanks.
John
18 years, 4 months
JacORB build problem
by Anthony Green
The rawhide JacORB doesn't build with gcj 4.1 because of
incompatibilities between libgcj's org.omg.CORBA and JacORB's
org.omg.CORBA. The JacORB code is referring to org.omg.CORBA fields
that only appear in the JacORB version of these classes, and there's no
way to override libgcj's built-in version at build time.
This problem is similar to the xml-commons-apis problem we've discussed
here and in bugzilla.
AG
18 years, 4 months
Re: [fedora-java] JacORB build problem
by Gary Benson
Jesse Keating wrote:
> On Wed, 2005-12-14 at 22:10 -0800, Anthony Green wrote:
> > It's not pretty, but the attached patch lets the jacorb RPM build.
> > Presumably other java alternatives have no problem building this.
> > I wonder why?
> >
> > > At runtime, as Mark said, these classes are BC-compiled and can
> > > be overridden via extdirs.
> >
> > Jacorb already intalls a "java" wrapper called "jaco" that does
> > this.
> >
> > Gary - please consider adding the attached patch for jacorb.
>
> Anthony, were you able to get it to build using this patch? I
> applied the patch but when I push it through beehive it still
> doesn't build right.
I tried patching the extra exceptions away, but now it's giving wierd
exceptions from gnu.CORBA.ObjectCreator. The override definitly seems
not to have happened. Are these classes definitly BC-compiled?
Cheers,
Gary
18 years, 4 months
[Fwd: Re: [Fwd: Re: [fedora-java] JacORB build problem]]
by Mark Wielaard
Hi,
I asked Audrius, who wrote the org.omg corba implementation for GNU
Classpath to take a look at this. He isn't subscribed to the list so I
forward his reply (attached). Thanks for looking into this Audrius.
For those interested in free Corba, Audrius will give a Developer Talk
on the implementation during Fosdem 26/27 Februari in the GNU Classpath
hacker room. We are still working on the full program and still looking
for more exciting talks/presentations/demos (we don't have anybody
presenting the gcj related improvements Fedora Core 5 yet, hint...)
http://lists.gnu.org/archive/html/classpath/2005-11/msg00122.html
Cheers,
Mark
18 years, 4 months
