public inbox for
 help / color / mirror / Atom feed
From: Nathan Bryant <>
To: Jakob Praher <>
Subject: Re: building from source
Date: Thu, 17 Jun 2004 19:30:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1087493379.25341.14.camel@jaques2>

well the compiler issues are pretty interesting. the best way to fix 
them going forward may be to get things working on gcc 3.4, since that's 
what fedora 3 will ship.

the eclipse that ships with red hat enterprise used a "3.5-ssa" snapshot 
from the tree-ssa branch, but the issues surrounding this are murky: it 
corresponds to a snapshot from the tree-ssa branch from before 3.4 was 
released, and thus I'm not even certain that its C++/java abi 
corresponds exactly to any FSF compiler that will ever be released. 
Whether binaries compiled against its shared libraries will continue to 
be supported by redhat is anyone's guess. Even if a recent stabilized 
3.5-mainline snapshot were to be incorporated into rawhide for Eclipse 
purposes, there are still questions about giving nonstandard sonames to 
its shared libraries.

if you're not a gcc hacker you'll probably have more success with gcc3.4 
or the older gcc-ssa snapshots that are currently in red hat enterprise.

gcc3.4 may have more issues but the ones i've found so far appear to be 
more "peripheral" than what you are describing: there are problems with 
the verifier, but bytecode verification can probably be trivially turned 
off, for example.

3.5-ssa from RH enterprise is known to work, but it uses some hacks that 
aren't good enough for the main FSF respository - presumably, it just 
comments out bytecode verification entirely. Would a patch that 
implements a command line switch / environment variable equivalent in 
functionality to Sun Java's -Xverify:{none,all,remote} option have a 
chance of making it into the main FSF gcj/libgcj repository?

Jakob Praher wrote:

>hi all,
>out of curiosity I was trying to build eclipse from source.
>I am using debian/unstable and did a fresh cvs co and build of gcc head,
>which is using the tree-ssa stuff and I think the otable/atable gcj
>engine already.
>I was able to compile the first bunch of jars successfully, but at least
>after org.apache.coyote plugin gcj segfaults with:
>internal compiler error: segmentation fault
>Is there a version of gcc/gcj which is stable enough to work?
>Why is the compiler reporting a segfault in .java files, when the
>command line tells to build from a binary jar file? 
>Is there any trick?
>-- Jakob

      reply	other threads:[~2004-06-17 19:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17 17:36 Jakob Praher
2004-06-17 19:30 ` Nathan Bryant [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).