Re: Decimal float and the Cygwin build of GFortran.

[Brian Dessent <brian at dessent dot net>]

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/