From: Nathan Bryant <nbryant@optonline.net>
To: Jakob Praher <jp@hapra.at>
Cc: eclipse@sources.redhat.com
Subject: Re: building from source
Date: Thu, 17 Jun 2004 19:30:00 -0000 [thread overview]
Message-ID: <40D1F147.2050202@optonline.net> (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?
>
>thanks
>-- Jakob
>
>
>
>
prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40D1F147.2050202@optonline.net \
--to=nbryant@optonline.net \
--cc=eclipse@sources.redhat.com \
--cc=jp@hapra.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).