Message-ID: <468D750D.B75BD122@dessent.net>
Date: Thu, 05 Jul 2007 15:47:41 -0700
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Decimal float and the Cygwin build of GFortran.
References: <20070705130708 DOT GC3540 AT SALTERDUKE2> <468D20A0 DOT 95877AA4 AT dessent DOT net> <20070705221912 DOT GA3720 AT SALTERDUKE2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Brian Salter-Duke wrote:

> I understand all this, but this case seems an odd one to me. If I am
> missing a library I expect to find a clear error message that it needs
> it, but here I just got nothing. I agree that this not a cygwin problem.
> I have yet to update my old gfortran 4.2. on linux to 4.3 and I guess
> I will have the same problem as the linux needs upgrading too. I'll know
> what to expect than.

The default behavior on Windows in the case of a program that cannot
initialize because of a missing DLL is a graphical pop-up error message
box.  Cygwin intercepts this and just returns a non-zero exit status
code (53) because that is more in line with how things work on
Linux/BSD, where a command line program like gcc doesn't (and in fact
can't) generate graphical window of any kind.  And besides it would be
silly for a non-interactive command-line process to halt a build
indefinitely waiting on some nonexistant user to press an "OK" button. 
On a headless server this would be a real inconvenience.

I haven't looked at the details but I'm not sure how much functionality
is available in this error trap code, since I think it runs in the
limited context of a SEH handler where the process hasn't even fully
initialized since the error occured during process startup, and so any
kind of meaningful I/O (like printing an error) may be out of the
question.  Again on traditional POSIX operating systems you get a
textual error message but it's generated by the dynamic loader (ld.so)
not the binary that failed to initialize -- the equivalent of the
graphical pop-up that Windows would give if Cygwin did not suppress it.

Certainly the process that invoked the binary should be able to check
for a non-zero exit status, however, in the design of gcc the front-end
driver just invokes the cc1/cc1plus/f951 subprocess and it's this
subprocess that is responsible for printing error messages encountered
during compilation, and I guess the front-end driver assumes that when
cc1 exits with an error it has already printed the reason and so there's
no reason to do anything but terminate pass on its exit status, thus the
lack of any output.

One thing you can do is to make the exit status code ($?) part of your
shell prompt.  That way when you run a command and nothing happens and
you see the 53 code, you'll know that you are missing a DLL:

$ ./f951.exe --version ; echo $?
GNU F95 version 4.3.0 20070202 (experimental) (i686-pc-cygwin)
        compiled by GNU C version 4.3.0 20070202 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
0

$ mv /bin/cygmpfr-1.dll{,.tmp}

$ ./f951.exe --version ; echo $?
53

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/