public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Hans_Boehm@hp.com
To: gcc-gnats@gcc.gnu.org
Cc: tromey@redhat.com
Subject: java/2370: Behavior of main compilation without  --main is unfriendly
Date: Fri, 23 Mar 2001 15:56:00 -0000	[thread overview]
Message-ID: <20010323234616.16647.qmail@sourceware.cygnus.com> (raw)

>Number:         2370
>Category:       java
>Synopsis:       Behavior of main compilation without  --main is unfriendly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 23 15:56:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Hans Boehm
>Release:        gcc 3.0
>Organization:
>Environment:
All
>Description:
Currently if gcj is asked to link a program with no --main specified, it will blindly proceed, thus guaranteeing a moderatwly obscure linker error message in response to a simple compilation attempt like

gcj X.java

Since most naive users are likely to try invoking it this way first, it would be really nice if it were a bit friendlier.

Based on a brief discussion on the Java mailing list, there seems to be some tentative agreement that:

If the only file arguments are .java and .class files, and there is no --main:
  1) If there is exactly one file argument, generate the --main
  2) If there is more than one, issue a warning, suggesting --main.  (This gets a little tricky if there are nonstandard libraries involved, which might be hiding main.  If none are explicitly listed, a warning should certainly be safe.)

Per Bothner pointed out that simply issuing an error if the linker was invoked without --main would not be appropriate once C++ main programs are better supported with Java code.

Tom expressed some concerns about implied options.  I wouldn't be at all opposed if this were not officially supported, and even in case 1 we issued a warning, but then did the right thing anyway.  I think in case there really is only one "right thing".  And it's important to do that, since it determines whether most user's first attempt to use gcj succeeds or fails.  The warning would simultaneously teach users the proper way to invoke gcj for larger applications.
>How-To-Repeat:
gcj hello.java
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2001-03-23 15:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-23 15:56 Hans_Boehm [this message]
2003-05-12 18:19 Dara Hazeghi

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=20010323234616.16647.qmail@sourceware.cygnus.com \
    --to=hans_boehm@hp.com \
    --cc=gcc-gnats@gcc.gnu.org \
    --cc=tromey@redhat.com \
    /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).