Home > Archive > Fortran > March 2004 > Directions for installing GNU Fortran
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Directions for installing GNU Fortran
|
|
| Richard L Walker 2004-03-27, 12:17 am |
| Is there a simple way to install the system of GNU compilers that run
under Windows? I'm interested in compiling program written in C, C++
and Fortran -- and understand that the same GNU system handles each
using a front end. I checked out he GNU sites that I could locate and
find so much information it is possible to drown -- and still come up
empty. Anyone know if "how to set it up" info is available at any
particular URL that simply presents the facts? (I feel like a dumb
Joe Friday)
| |
| Helge Avlesen 2004-03-27, 12:17 am |
| Richard L Walker <rlwalker@granis.net> writes:
| Is there a simple way to install the system of GNU compilers that run
| under Windows? I'm interested in compiling program written in C, C++
| and Fortran -- and understand that the same GNU system handles each
| using a front end. I checked out he GNU sites that I could locate and
| find so much information it is possible to drown -- and still come up
| empty. Anyone know if "how to set it up" info is available at any
| particular URL that simply presents the facts? (I feel like a dumb
| Joe Friday)
if you have high speed internet connection you can go to
http://www.cygwin.com/
download and run the installer - it will let you choose what GNU tools
to install, you will get not only compilers but the whole ls,bash, awk
etc set of tools as well (if you want)
--
Helge
| |
| Charles Russell 2004-03-27, 12:17 am |
|
"Helge Avlesen" wrote
> if you have high speed internet connection you can go to
>
> http://www.cygwin.com/
>
> download and run the installer - it will let you choose what GNU tools
> to install, you will get not only compilers but the whole ls,bash, awk
> etc set of tools as well (if you want)
>
To get g77 and the full suite of linux compilers and development tools,
select the full "development" package to download in addition to the base
package. You will also need to specify an editor, which for some reason is
not included in the development package. (Get vim.) If you want to
distribute executables that run without cygwin, also get the mingw package.
You don't need a high speed connection. On a 40 kbs telephone line, I can
get all the above in one overnight download. If you want to fool with
graphics (x-cygwin), add two more overnights, but the above will suffice for
console applications.
| |
| Jeff Ryman 2004-03-27, 12:17 am |
| On Sat, 20 Mar 2004 00:41:17 -0600, Richard L Walker
<rlwalker@granis.net> wrote:
>Is there a simple way to install the system of GNU compilers that run
>under Windows? I'm interested in compiling program written in C, C++
>and Fortran -- and understand that the same GNU system handles each
>using a front end. I checked out he GNU sites that I could locate and
>find so much information it is possible to drown -- and still come up
>empty. Anyone know if "how to set it up" info is available at any
>particular URL that simply presents the facts? (I feel like a dumb
>Joe Friday)
To get the mingw version with GCC 3.2, do the following:
From the F download site, ftp://ftp.swcp.com/pub/walt/F/
get f_win_mingw_031017.zip, then unzip where you want. I used the
root directory, creating directories C:\mingw\... and C:\F_031017\...
If you don't want the F compiler, delete C:\F_031017\...
Add C:\mingw\bin to the path, and you are ready to go.
If you want a later GCC (3.3.1), you can download from www.mingw.org
Jeff Ryman
email: rymanjc_at_
excite_dot_com
| |
| E P Chandler 2004-03-27, 12:17 am |
| Richard L Walker <rlwalker@granis.net> wrote in message news:<dcmn50tcpns9evqs3ardvigirg1vk9f8el@4ax.com>...
> Is there a simple way to install the system of GNU compilers that run
> under Windows? I'm interested in compiling program written in C, C++
> and Fortran -- and understand that the same GNU system handles each
> using a front end. I checked out he GNU sites that I could locate and
> find so much information it is possible to drown -- and still come up
> empty. Anyone know if "how to set it up" info is available at any
> particular URL that simply presents the facts? (I feel like a dumb
> Joe Friday)
see http://www.stat.sc.edu/~habing/courses/740/mingw.html for setup
instructions.
An alternative to Cygwin is the MinGW (Minimalist GNU on Windows) set
of tools. The advantages to these over Cygwin is that there is only
one distribution to get (the MSYS tools are optional) and the minimal
set of things you need to get started is smaller. If you want to work
from the command line but you don't really need a Unix like
environment, I think MinGW is more suited. In addition, it is easier
(IMO) to mix components created with MinGW with other Windows
programs.
Let's say you install the programs to c:\foo. Then make sure that
c:\foo\bin has been added to your PATH. To compile your Fortran
program, for example in file bar.f, from the command prompt issue g77
bar.f -o bar.exe. To compile your C program, for example in file
baz.c, from the command prompt issue gcc baz.c -o baz.exe
This should get you started.
| |
| Charles Russell 2004-03-27, 12:17 am |
|
"E P Chandler" wrote
>
> An alternative to Cygwin is the MinGW (Minimalist GNU on Windows) set
> of tools. The advantages to these over Cygwin is that there is only
> one distribution to get (the MSYS tools are optional) and the minimal
> set of things you need to get started is smaller. If you want to work
> from the command line but you don't really need a Unix like
> environment, I think MinGW is more suited. In addition, it is easier
> (IMO) to mix components created with MinGW with other Windows
> programs.
Some like the unix environment, some (I suppose) like Windows. But you can
get both cygwin and mingw for the price of one.
| |
| Richard L Walker 2004-03-27, 12:17 am |
| Thanks - I'll give it a whirl.
| |
| Richard L Walker 2004-03-27, 12:17 am |
| Thank you.
| |
| Clive Page 2004-03-27, 12:17 am |
| In message <7f64e2ff.0403201532.52488450@posting.google.com>, E P
Chandler <epc8@juno.com> writes
>see http://www.stat.sc.edu/~habing/courses/740/mingw.html for setup
>instructions.
I suppose I should be pleased that the Fortran manual the author of this
page recommends is my own, but I'm upset that the code example he gives
contains:
real*4 tempC, tempF, FACTOR
integer*2 ZERO_SHIFT
Why do people do this? The "*4" on the end of REAL does absolutely
nothing, except render the program non-Standard. The "*2" on the
INTEGER does little except bring on the risk that some student will copy
the style when really needing an integer capable of holding a larger
number than 32767. I find it extraordinary that these *N conventions
persist: can anyone suggest an explanation?
--
Clive Page
| |
| E P Chandler 2004-03-27, 12:17 am |
| Clive Page <junk@page.demon.co.uk> wrote in message news:<Gjz$vBCnEZXAJwJJ@page.demon.co.uk>...
> In message <7f64e2ff.0403201532.52488450@posting.google.com>, E P
> Chandler <epc8@juno.com> writes
>
> I suppose I should be pleased that the Fortran manual the author of this
> page recommends is my own, but I'm upset that the code example he gives
> contains:
>
> real*4 tempC, tempF, FACTOR
> integer*2 ZERO_SHIFT
>
> Why do people do this? The "*4" on the end of REAL does absolutely
> nothing, except render the program non-Standard. The "*2" on the
> INTEGER does little except bring on the risk that some student will copy
> the style when really needing an integer capable of holding a larger
> number than 32767. I find it extraordinary that these *N conventions
> persist: can anyone suggest an explanation?
Since this is one of the classic beginning C programs, I suggest that
the *N is a carryover from C, not the usual practice of a Fortran
programmer.
[OT] (Of course my old habits are not easy to break. When I learned
FORTRAN there was only real, double precision and complex - no
character variables at all.)
| |
| jan van oosterwijk 2004-03-27, 12:17 am |
| Clive Page <junk@page.demon.co.uk> wrote in message news:<Gjz$vBCnEZXAJwJJ@page.demon.co.uk>...
> In message <7f64e2ff.0403201532.52488450@posting.google.com>, E P
> Chandler <epc8@juno.com> writes
>
> I suppose I should be pleased that the Fortran manual the author of this
> page recommends is my own, but I'm upset that the code example he gives
> contains:
>
> real*4 tempC, tempF, FACTOR
> integer*2 ZERO_SHIFT
>
> Why do people do this? The "*4" on the end of REAL does absolutely
> nothing, except render the program non-Standard. The "*2" on the
> INTEGER does little except bring on the risk that some student will copy
> the style when really needing an integer capable of holding a larger
> number than 32767. I find it extraordinary that these *N conventions
> persist: can anyone suggest an explanation?
I don't have an explanation, but I totally agree with Clive.
A related anachronism I frequently find is
read(5, ...
Write(6, ...
instead of
read (*, ...
write(*, ...
Jan van Oosterwijk
mailto : Jan dot vanOosterwijk at Wanadoo dot NL
| |
| Richard Maine 2004-03-27, 12:17 am |
| jvo_36@hotmail.com (jan van oosterwijk) writes:
> A related anachronism I frequently find is
> read(5, ...
> Write(6, ...
>
> instead of
> read (*, ...
> write(*, ...
There I'm going to disagree with you. I pretty much never
use the * units for anything other than quick hacks (usually
debugging printouts). Of course, I do use variables for the luns
instead of the hard-coded units 5 and 6.
My main reason is consistency. Life is much simpler if unit
numbers are always integers (or it would be ok if they were always
some other type). The * is a syntactic wart that isn't compatible
with anything.
In particular, if I have a procedure that might sometimes write
to standard output, but might other times write to some other
file, it is trivial if I use unit numbers - I just call it
with the appropriate unit number and everything works. With *,
there is no way other than to code an IF test and separate write
statements. This comes up a lot, not just on occasion; I often
want the capability to redirect output for a while from within
my program. (The "from within my program" part is important here;
no, doing it at the system shell is *NOT* adequate because I need
to be able do it for individual commands within my code - basically
its own internal command line redirection).
The fundamental problem is that * is a hard-wired piece of syntax -
not a variable. Might just as well be the hard-coded 5 and 6
for all the flexibility it has. Yes, it is portable, but it is
not flexible.
I do have to have a piece of systen-dependent code that sets op
a unit number connected to standard input/output, but that's
pretty easy. Actually, with most current compilers, all I need
to do for that is set the value of the lun to 5 or 6, but I
am set up so that I have a spot for special OPEN statements or
whatever else might be needed, if 5 and 6 aren't automatically
set up right for me.
Note that the f2003 draft makes life slightly easier for using luns.
Namely the standard defines named parameters for the appropriate luns.
Most compilers will likely just set those parameters to 5 and 6,
but in any case, I'd no longer have to worry about what particular
compilers needed - using the paramaters specified by the standard
will make the code portable.
--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net
| |
| James F. Cornwall 2004-03-27, 12:17 am |
| Clive Page wrote:
>
> In message <7f64e2ff.0403201532.52488450@posting.google.com>, E P
> Chandler <epc8@juno.com> writes
>
> I suppose I should be pleased that the Fortran manual the author of this
> page recommends is my own, but I'm upset that the code example he gives
> contains:
>
> real*4 tempC, tempF, FACTOR
> integer*2 ZERO_SHIFT
>
> Why do people do this? The "*4" on the end of REAL does absolutely
> nothing, except render the program non-Standard. The "*2" on the
> INTEGER does little except bring on the risk that some student will copy
> the style when really needing an integer capable of holding a larger
> number than 32767. I find it extraordinary that these *N conventions
> persist: can anyone suggest an explanation?
>
> --
> Clive Page
In my case, we have a large base of old legacy code that specified a lot
of <var>*2 and <var>*4 declarations because it needed to distinguish
between the default INTEGER*2 and the *4 size most of the code wanted.
This was sometime back in the 70s, I wasn't there (!), but we have a
fair chunk of code still in active use from those days. So the
programmers thru the years have acquired the habit of keeping the size
specs in the declarations. We also have some vendor code (an Embedded
SQL preprocessor and Ingres database access routines) that requires
Integer*2 variables as null-flag placeholder variables. It may not be
portable, but it's not going away anytime soon...
Jim C
--
****************************************
************
** Facilior veniam posterius quam prius capere! **
****************************************
************
** James F. Cornwall, sole owner of all opinions **
** expressed in this message... **
****************************************
************
| |
| John Appleyard 2004-03-27, 12:18 am |
| Charles Russell wrote:
> "E P Chandler" wrote
>
>
>
> Some like the unix environment, some (I suppose) like Windows. But you can
> get both cygwin and mingw for the price of one.
>
>
I've noticed that the Cygwin and MinGW versions (both 3.3.1) give very
different execution times on our benchmarks (same code and compiler
switches used for both). On some benchmarks the difference is a factor
of more than 2. Can anyone explain this?
--
John Appleyard - (send email to john!news@.. rather than spamtrap@..)
Polyhedron Software
Programs for Programmers - QA, Compilers, Graphics, Consultancy
********* Visit our Web site on http://www.polyhedron.co.uk/ *********
| |
| Tim Prince 2004-03-27, 12:18 am |
|
"John Appleyard" <spamtrap@polyhedron.com> wrote in message
news:4061C207.8030003@polyhedron.com...
> I've noticed that the Cygwin and MinGW versions (both 3.3.1) give very
> different execution times on our benchmarks (same code and compiler
> switches used for both). On some benchmarks the difference is a factor
> of more than 2. Can anyone explain this?
>
Presumably, it has to do with the different characteristics of the support
..dll's. cygwin1.dll is necessarily much larger than msvcrt.dll et al. It
embodies posix emulations and other functionality not present in the mingw
environment, whether your program uses it or not. It's compiled mostly by
g++, with little attention to Windows-specific optimizations. The C
run-time implementation of I/O is entirely different. Your comparisons might
vary by hardware platform, amount of RAM, and Windows version.
| |
| John Appleyard 2004-03-27, 12:18 am |
| Tim Prince wrote:
> "John Appleyard" <spamtrap@polyhedron.com> wrote in message
> news:4061C207.8030003@polyhedron.com...
>
>
> Presumably, it has to do with the different characteristics of the support
> .dll's. cygwin1.dll is necessarily much larger than msvcrt.dll et al. It
> embodies posix emulations and other functionality not present in the mingw
> environment, whether your program uses it or not. It's compiled mostly by
> g++, with little attention to Windows-specific optimizations. The C
> run-time implementation of I/O is entirely different. Your comparisons might
> vary by hardware platform, amount of RAM, and Windows version.
>
>
The comparison was done on a single machine. There's no consistent
"best buy" - both have dramatic wins. I have found another benchmark
which shows a factor of 5 difference! I've also noticed detailed
differences in floating point ouputs of the type one often finds when
comparing different compilers. Clearly the Cygwin and MinGW versions of
g77 count as "different compilers".
--
John Appleyard - (send email to john!news@.. rather than spamtrap@..)
Polyhedron Software
Programs for Programmers - QA, Compilers, Graphics, Consultancy
********* Visit our Web site on http://www.polyhedron.co.uk/ *********
| |
| Charles Russell 2004-03-29, 3:39 pm |
|
"John Appleyard" wrote
.. Clearly the Cygwin and MinGW versions of
> g77 count as "different compilers".
What happens when cygwin g77 is invoked with the -mno-cygwin compiler
option, so as not to require the cygwin dll for execution? I believe this
links mingw libraries. Is it the same as using mingw directly?
| |
| Charles Russell 2004-03-29, 11:32 pm |
|
"Charles Russell" wrote
> select the full "development" package to download in addition to the base
> package. If you want to
> distribute executables that run without cygwin, also get the mingw
package.
errata: change "package" to "setup option"
>
> If you want to fool with
> graphics (x-cygwin), add two more overnights,
errata: change "x-cygwin" to "cygwin-xfree"
| |
| John Appleyard 2004-03-30, 7:39 am |
| Charles Russell wrote:
> "John Appleyard" wrote
>
> . Clearly the Cygwin and MinGW versions of
>
>
>
> What happens when cygwin g77 is invoked with the -mno-cygwin compiler
> option, so as not to require the cygwin dll for execution? I believe this
> links mingw libraries. Is it the same as using mingw directly?
>
>
Yes - it does seem so. The timings are very similar with -mno-cygwin.
--
John Appleyard - (send email to john!news@.. rather than spamtrap@..)
Polyhedron Software
Programs for Programmers - QA, Compilers, Graphics, Consultancy
********* Visit our Web site on http://www.polyhedron.co.uk/ *********
|
|
|
|
|