g77 and gcc40

0 views
Skip to first unread message

Joel Mosher

unread,
Nov 23, 2004, 5:18:48 PM11/23/04
to
I've just installed FreeBSD 5.3 and noticed the gcc40 port. I've been
using gcc34 and decided to give gcc40 a try. After I installed gcc40
I looked for the version of g77 that comes with it and couldn't find it.

Is g77 still included in gcc or is it replaced by gfortran, or what?

Thomas Koenig

unread,
Nov 23, 2004, 5:21:49 PM11/23/04
to
Joel Mosher <kb6...@pacbell.net> wrote:

>Is g77 still included in gcc

No.

>or is it replaced by gfortran,

Yes.

>or what?

Uh ... :-)

Tim Prince

unread,
Nov 23, 2004, 7:09:47 PM11/23/04
to

"Thomas Koenig" <Thomas...@online.de> wrote in message
news:co0d5t$dvd$1...@meiner.onlinehome.de...

> Joel Mosher <kb6...@pacbell.net> wrote:
>
> >Is g77 still included in gcc
>
> No.
>
> >or is it replaced by gfortran,
>
> Yes.
>
but it's optional, no longer a default.


David Ham

unread,
Nov 24, 2004, 12:20:46 PM11/24/04
to
On Wed, 24 Nov 2004 11:01:16 -0600
Mike Walters <walters@wisp_DOT_physics_DOT_wisc.edu> wrote:

> Does that mean that there will no longer be a "g77" command? If so,
> that's going to break a lot of make files.
>

What g77 points to is pretty much a distribution and/or administration
issue. One imagines that most distributions will cause f77 and g77 to point to
gfortran by default. If gfortran is optional the distro might package it
separately, but how hard is "apt-get install gfortran"?

(I'm assuming that Mike Walters is refering to GNU/*nix systems since
one imagines that they are the only ones where software simply assumes
g77 is around).

David

Greg Lindahl

unread,
Nov 24, 2004, 12:25:36 PM11/24/04
to
In article <co2eos$pgl$1...@news.doit.wisc.edu>,
Mike Walters <walters@wisp_DOT_physics_DOT_wisc.edu> wrote:

>Does that mean that there will no longer be a "g77" command? If so,
>that's going to break a lot of make files.

What Linux distributions do with something is different from what the
maintainers of the something do with it. You'll have to wait until you
see a distro package up the 4.0 compilers to see.

-- greg

Mike Walters

unread,
Nov 24, 2004, 12:01:16 PM11/24/04
to

Does that mean that there will no longer be a "g77" command? If so,
that's going to break a lot of make files.


--

"It is enough that the people know there was an election. The people who
cast the votes decide nothing. The people who count the votes decide
everything."

-- Joseph Stalin

Paul Van Delst

unread,
Nov 24, 2004, 1:23:22 PM11/24/04
to
Mike Walters wrote:
> Tim Prince wrote:
>
>> "Thomas Koenig" <Thomas...@online.de> wrote in message
>> news:co0d5t$dvd$1...@meiner.onlinehome.de...
>>
>>> Joel Mosher <kb6...@pacbell.net> wrote:
>>>
>>>
>>>> Is g77 still included in gcc
>>>
>>>
>>> No.
>>>
>>>
>>>> or is it replaced by gfortran,
>>>
>>>
>>> Yes.
>>>
>>
>> but it's optional, no longer a default.
>>
>
>
> Does that mean that there will no longer be a "g77" command? If so,
> that's going to break a lot of make files.

ln -s gfortran g77

should solve that problem. (And introduce a heap of others I'm sure. :o)

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Toon Moene

unread,
Nov 24, 2004, 3:58:38 PM11/24/04
to
Paul Van Delst wrote:

> ln -s gfortran g77
>
> should solve that problem. (And introduce a heap of others I'm sure. :o)

Ya betch-a (on introducing lots of problems). Not all extensions g77
supports are already supported by gfortran, and we probably *have* to
concentrate on fixing outright bugs *first*. There are only a few
months left to release (something of the order of 3 or 4).

What we hope *distributors* (whether Linux or other) will do is provide
a /opt/bin/g77 package that can be called by the names g77 or f77.

In that way, people can just use the compiler that happens to compile
their code (or compare the two compilers in case both of them compile
their code :-)

Hope this helps,

--
Toon Moene - e-mail: to...@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

Harald Anlauf

unread,
Nov 24, 2004, 5:17:27 PM11/24/04
to
Toon Moene <to...@moene.indiv.nluug.nl> writes:

> Not all extensions g77
> supports are already supported by gfortran, and we probably *have* to
> concentrate on fixing outright bugs *first*.

That's nice to hear. I take that as a commitment. I have some "legacy
stuff" that works well with g77, but cannot be compiled with gfortran.
Between 5 to 10% of the source files lead to ICEs with the latter.
(Fortran 90+ code is somewhat better.)

And in case somebody asks: yes, I have reported all corresponding
compiler bugs that I could isolate, and some of them have been known for
quite some time.

> There are only a few
> months left to release (something of the order of 3 or 4).

Hmmm. Given the number of known bugs on gfortran.org that affect me,
this time scale sounds *very* optimistic. What do you suggest to people
who want to upgrade to a newer gcc but don't want to break their
applications? Just keep the old compiler in addition to the new one, or
go even back to f2c?

(The (sometimes so-called) "other compiler" currently fares noticeably
better on the same code, but that's probably not what the gfortran
people would like to hear. YMMV.)

--
Cheers,
-ha

Steven G. Kargl

unread,
Nov 24, 2004, 5:33:08 PM11/24/04
to
In article <ubhdned...@heplix.ikp.physik.tu-darmstadt.de>,

Harald Anlauf <anl...@hep.tu-darmstadt.de> writes:
> Toon Moene <to...@moene.indiv.nluug.nl> writes:
>
>> Not all extensions g77
>> supports are already supported by gfortran, and we probably *have* to
>> concentrate on fixing outright bugs *first*.
>
> That's nice to hear. I take that as a commitment. I have some "legacy
> stuff" that works well with g77, but cannot be compiled with gfortran.

Then use g77, which is contained in version of gcc prior to
the yet-to-be-released 4.0.0.

> Hmmm. Given the number of known bugs on gfortran.org that affect me,
> this time scale sounds *very* optimistic. What do you suggest to people
> who want to upgrade to a newer gcc but don't want to break their
> applications?

See above. Of course, your F90/95 code may not compile with g77.

> (snip), or go even back to f2c?

Is this rhetorical (pun intended)?

> (The (sometimes so-called) "other compiler" currently fares noticeably
> better on the same code, but that's probably not what the gfortran
> people would like to hear. YMMV.)

Most of the gfortran people don't really care about the
"other compiler".

--
Steve

Charles Russell

unread,
Nov 25, 2004, 1:48:42 PM11/25/04
to

"Mike Walters" wrote

>
> Does that mean that there will no longer be a "g77" command? If so,
> that's going to break a lot of make files.
>

All make implementations that I have used employ the environment variables
$FC and $FFLAGS to designate the compiler and its default settings. The
makefiles themselves, if portably written, do not have to be changed when
you switch compilers or computers.

However, I understand that there is no portable way to write makefiles for
f90 since the implementation of modules is not standardized. That is one
reason, in my opinion, to avoid modules.


beli...@127.0.0.1

unread,
Nov 25, 2004, 6:07:00 PM11/25/04
to

>> (The (sometimes so-called) "other compiler" currently fares noticeably
>> better on the same code, but that's probably not what the gfortran
>> people would like to hear. YMMV.)
>
>Most of the gfortran people don't really care about the
>"other compiler".

Based on my experience compiling codes originally written for Compaq Visual
Fortran and Lahey/Fujitsu, g95, but not gfortran, currently deserves the
term "Fortran 95 compiler". Gfortran is a Fortran 77 compiler with many F90
and F95 extensions. There are still a few bugs in g95, but the same could
be said even of the well-respected Compaq Visual Fortran.

I hope that gfortran documentation mentions prominently that a more mature,
free Fortran 95 compiler exists. Most prospective users care more about the
quality of a compiler than its development process. Ignorance and confusion
about Fortran is very widespread, and replacing g77 with a compiler that
is not strictly F77, F90, or F95 will do nothing to dispel this.

I do wish the gfortran volunteers success. The continuing development of
g95 seems to depend largely on the effort of one man, which worries me a
little, although his effort so far has been heroic.

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Steven G. Kargl

unread,
Nov 25, 2004, 6:56:31 PM11/25/04
to
In article <41a66...@127.0.0.1>,

"beli...@aol.com" <beli...@127.0.0.1:7501> writes:
>
> ka...@c-67-168-59-70.client.comcast.net (Steven G. Kargl) wrote:
>
>>> (The (sometimes so-called) "other compiler" currently fares noticeably
>>> better on the same code, but that's probably not what the gfortran
>>> people would like to hear. YMMV.)
>>
>>Most of the gfortran people don't really care about the
>>"other compiler".
>
> Based on my experience compiling codes originally written for Compaq Visual
> Fortran and Lahey/Fujitsu, g95, but not gfortran, currently deserves the
> term "Fortran 95 compiler". Gfortran is a Fortran 77 compiler with many F90
> and F95 extensions. There are still a few bugs in g95, but the same could
> be said even of the well-respected Compaq Visual Fortran.

Based on my experience, gfortran compiles all my F90/95 code. Therefore,
it deserves the term "Fortran 95 compiler". This, of course, is as
absurd as your statement above.

Scanning the GCC bug reports, I note no entries for beliavsky. Perhaps,
the gfortran developers can meet your expectations if you're willing to
file bug reports.

> I hope that gfortran documentation mentions prominently that a more mature,
> free Fortran 95 compiler exists. Most prospective users care more about the
> quality of a compiler than its development process.

Then, I suppose gfortran should also have prominent documentation about
CVF, IVF, Absoft, Lahey, NAG, et al..., which are all more mature than
gfortran and g95.

The gfortran source files contain the appropriate copyright notices.
The cause of the fork of gfortran from g95 are well-known to those
who seek the truth.

http://gfortran.org/index.php/Gfortran/TheOtherGccBasedF95Compiler

> Ignorance and confusion about Fortran is very widespread, and replacing
> g77 with a compiler that is not strictly F77, F90, or F95 will do nothing
> to dispel this.

There are no *strictly* F77, F90, or F95 compilers available. All compilers
that I've used have some nonstandard features. And, if you look, you'll find
that gfortran actually supports some F2003 features.

> I do wish the gfortran volunteers success. The continuing development of
> g95 seems to depend largely on the effort of one man, which worries me a
> little, although his effort so far has been heroic.

More worrisome is the wanton violation of the copyright that the
author has placed on his code and the code the others have
contributed to g95.

--
Steve

beli...@127.0.0.1

unread,
Nov 25, 2004, 7:10:35 PM11/25/04
to

ka...@c-67-168-59-70.client.comcast.net (Steven G. Kargl) wrote:
>In article <41a66...@127.0.0.1>,
> "beli...@aol.com" <beli...@127.0.0.1:7501> writes:
>>
>> ka...@c-67-168-59-70.client.comcast.net (Steven G. Kargl) wrote:
>>
>>>> (The (sometimes so-called) "other compiler" currently fares noticeably
>>>> better on the same code, but that's probably not what the gfortran
>>>> people would like to hear. YMMV.)
>>>
>>>Most of the gfortran people don't really care about the
>>>"other compiler".
>>
>> Based on my experience compiling codes originally written for Compaq Visual
>> Fortran and Lahey/Fujitsu, g95, but not gfortran, currently deserves the
>> term "Fortran 95 compiler". Gfortran is a Fortran 77 compiler with many
F90
>> and F95 extensions. There are still a few bugs in g95, but the same could
>> be said even of the well-respected Compaq Visual Fortran.
>
>Based on my experience, gfortran compiles all my F90/95 code. Therefore,
>it deserves the term "Fortran 95 compiler". This, of course, is as
>absurd as your statement above.
>
>Scanning the GCC bug reports, I note no entries for beliavsky. Perhaps,
>the gfortran developers can meet your expectations if you're willing to
>file bug reports.

I have done so, using my real name.

>
>> I hope that gfortran documentation mentions prominently that a more mature,
>> free Fortran 95 compiler exists. Most prospective users care more about
the
>> quality of a compiler than its development process.
>
>Then, I suppose gfortran should also have prominent documentation about
>CVF, IVF, Absoft, Lahey, NAG, et al..., which are all more mature than
>gfortran and g95.

I don't expect for-profit companies to advertise their competitors. Gfortran
is a commendable volunteer effort to benefit the Fortran community, and one
way they can do this is by recommending that users also install g95 when
it better suits their needs.

>> Ignorance and confusion about Fortran is very widespread, and replacing
>> g77 with a compiler that is not strictly F77, F90, or F95 will do nothing
>> to dispel this.
>
>There are no *strictly* F77, F90, or F95 compilers available. All compilers
>that I've used have some nonstandard features. And, if you look, you'll
find
>that gfortran actually supports some F2003 features.

A compiler is an Fxx compiler if it has an option where it compiles all legal
Fxx code and warns about non-Fxx code. Allowing extensions does not make
a compiler not a strict Fxx compiler.

Janne Blomqvist

unread,
Nov 26, 2004, 2:30:12 AM11/26/04
to
On 2004-11-24, Harald Anlauf <anl...@hep.tu-darmstadt.de> wrote:

> Toon Moene <to...@moene.indiv.nluug.nl> writes:
>> There are only a few
>> months left to release (something of the order of 3 or 4).
>
> Hmmm. Given the number of known bugs on gfortran.org that affect me,
> this time scale sounds *very* optimistic. What do you suggest to people
> who want to upgrade to a newer gcc but don't want to break their
> applications? Just keep the old compiler in addition to the new one, or
> go even back to f2c?

Don't worry.

I suspect that a lot of Linux distributions will use gcc 3.4.x as the
system compiler until gcc 4.1 is available (in about 16 months). The
same thing happened with gcc 3.0, most distributions didn't jump on
the gcc 3 bandwagon until gcc 3.2 (which IIRC really was gcc 3.1 with
a minor C++ ABI change).

That being said, most distributors do provide packages of older and/or
newer gcc releases.

Thus I predict that the timeline will look something like:

System compiler Gfortran

Now: Gcc 3.3/3.4 CVS snapshot

Next summer: Gcc 3.4.x Optional gcc 4.0 rpm/deb

2 years: Gcc 4.1 Automagically included


I do hope that by gcc 4.1 gfortran will be about as stable as g77 is
now. Anyways, even at that point I think distributions still will
package gcc 3.4 as an optional package, just like many distros package
gcc 2.95 today.

--
Janne Blomqvist

Richard Maine

unread,
Nov 26, 2004, 12:22:17 PM11/26/04
to
"Charles Russell" <STOPwor...@bellsouth.net> writes:

> However, I understand that there is no portable way to write makefiles for
> f90 since the implementation of modules is not standardized.

Neither is the implementation of external procedures, or for that matter,
the use of compilers to implement the language. Thus I suggest that you
avoid such things as external procedures because their implementation isn't
standardized. :-)

In spite of the nonstandardization of such things, people do manage to get
thnigs done. I do, and I've noticed that so do others. I use modules
extensively and I have never had and more difficulty porting them than
I have had with porting other things. That includes the use of make.

Yes, there have been some implementations of modules that were a bit
different from others. However, current practice has been converging you
a defacto standard. If you want to drag out noncurrent compilers, there
are *PLENTY* of good old f77 compilers that are incompatible with any
makefile scheme that you might have (and that have run on systems that
didn't even have a make available).

Today, modules have about the same makefile portability as other
things in practice. This doesn't mean that you never have to do some
porting work, but no more than for other things. Modules are *NOT*
the biggest bar to makefile portability that I see in actual practice
today.

There are systems today for which I can't count on porting my makefiles...
but that's not because of modules. To port to Lahey Fortran, I throw out
all my makefiles and use Lahey's very different build mechanism; IIRC
(it has been a while), they don't even include a make implementation.
(Old versions used to include... OPUS make, I think it was, but then they
stopped). Yes, I know that I could use independent 3rd-party implementations
of make; if it was just for myself, perhaps I would. But this wouldn't go
over well with my Windows users - I need things to work with what they
will actually have - not what they might be able to get. I certainly
can't tell them that they have to install something like Cygwin. (Don't
bother to tell me about how easy it is. I know. Tell all my users.
Oh, and be prepared to explain how they will do this when they are on systems
behind firewalls, and with strong controls on approval of software
installation, and in other conditions that you don't know. No, I just
can't tell them that's a requirement.)

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Charles Russell

unread,
Nov 26, 2004, 12:49:25 PM11/26/04
to

"Richard Maine" wrote

> current practice has been converging (on)
> a defacto standard.

Good. I can wait.

To port to Lahey Fortran, I throw out
> all my makefiles and use Lahey's very different build mechanism; IIRC
> (it has been a while), they don't even include a make implementation.

I quickly abandoned Lahey because of its abysmal performance with bounds
check enabled, but before that, I got it to work with my unix makefiles by
using MKS make and writing a shell script to emulate "ar". I can't do that
myself for Salford because of the DOS syntax in its command line, but it
should be easy for a shell guru to write a unix wrapper.

The nicest thing about unix is that hardly anything in my programming
environment has changed in the last 15 years. Not even a new editor. No
more hassle porting to a new box. Just more flops for fewer dollars.


Ron Shepard

unread,
Nov 26, 2004, 2:16:29 PM11/26/04
to
[hijacked from another thread...]

In article <87r7mg1...@vega.site>,
Richard Maine <nos...@see.signature> wrote:

> In spite of the nonstandardization of such things, people do manage to get
> thnigs done. I do, and I've noticed that so do others. I use modules
> extensively and I have never had and more difficulty porting them than
> I have had with porting other things. That includes the use of make.

What is the current status of designing portable makefiles (on
unix-like OSs and beyond) in large programming projects with f90
modules? It seems that there are several possible ways to do
things, and without a lot of personal experience, it isn't clear to
me which is the best approach. So what does c.l.f. as a whole
suggest as the current best approach.

I'm assuming in a large project that source code is spread across
several directories, and both object libraries and module files need
to be shared among the various directories.

One choice to be made is whether and how to group the module files
into a single directory. Although another name might be
appropriate, let me assume that the appropriate target directory for
a particular project is named "$(PROJECT)/modules". One option for
designing a makefile structure would be to copy the appropriate
file.f90 to this directory, compile it in that location, and then
delete (or move) the source file and object file, leaving the *.mod
files (or whatever they happen to be called by that compiler).
After this is done for all of the source files that contain shared
modules, this directory should then be included in the search path
of the compiler for the subsequent program builds (i.e. the same as
shared object libraries are referenced in the analogous
"$(PROJECT)/lib" directory.

Another option would be to create the module files in the original
source code directories, and then figure out some way to move them
to the "$(PROJECT)/modules" directory. If a make macro $(MOD) is
defined for the file extension, then this could be done in a fairly
portable way by having the various makefiles include a
machine-dependent configuration file (i.e. the same place that the
machine-dependent compiler name and options are placed).

Another option would be to leave the module files scattered around
in the various source code directories. This would make writing the
various makefiles for the individual programs in the project that
need access to these files a little harder, but it avoids many of
the complications of figuring out what does or doesn't need to be
moved into $(PROJECT)/* directories.

What is the best approach? And why? Are there other approaches
that are better?

Is is correct now that all of the module information can be assumed
to be in the *.$(MOD) files? Are there any f90 compilers left that
need access to the original .f90 source code, or to some other
compiler-generated file, in addition to the compiled module file?

When defining dependencies within the individual makefiles, should
the $(MOD) file be listed directly? In the past I've found that
referencing only the local *.o files seems to be simpler for smaller
programming projects. However, for shared module files (like shared
.a files), it would seem that some kind of explicit dependency is
appropriate.

$.02 -Ron Shepard

beli...@127.0.0.1

unread,
Nov 26, 2004, 5:06:17 PM11/26/04
to

Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:
>[hijacked from another thread...]
>
>In article <87r7mg1...@vega.site>,
> Richard Maine <nos...@see.signature> wrote:
>
>> In spite of the nonstandardization of such things, people do manage to
get
>> thnigs done. I do, and I've noticed that so do others. I use modules
>> extensively and I have never had and more difficulty porting them than
>> I have had with porting other things. That includes the use of make.
>
>What is the current status of designing portable makefiles (on
>unix-like OSs and beyond) in large programming projects with f90
>modules?

At the Fortran:Tools section of the Open Directory at http://www.dmoz.org/Computers/Programming/Languages/Fortran/Tools/
, there are links to several sites with programs that create make files:

Fmkmf
http://www.met.ed.ac.uk/~hcp/fmkmf.html
GNU Make Variables and Pattern Rules
http://www.theochem.uwa.edu.au/fortran/make_variables/

Makemake
http://www.fortran.com/fortran/makemake.perl

Perl scripts for Fortran
http://www.arsc.edu/~kate/Perl/

Greg Lindahl

unread,
Nov 26, 2004, 6:14:07 PM11/26/04
to
In article <41a67...@127.0.0.1>,
beli...@aol.com <beli...@127.0.0.1:7501> wrote:

>I don't expect for-profit companies to advertise their competitors. Gfortran
>is a commendable volunteer effort to benefit the Fortran community, and one
>way they can do this is by recommending that users also install g95 when
>it better suits their needs.

Given that you posted this on American Thanksgiving, it's remarkably
ungracious. Gfortran documentation already mentions g95. You're
criticizing them for not being enthusiastic enough about it?
Sheez. Get a grip. Take 2, they're cheap.

-- greg

B52B

unread,
Nov 29, 2004, 8:38:27 AM11/29/04
to
beli...@aol.com wrote:
>
>
> At the Fortran:Tools section of the Open Directory at http://www.dmoz.org/Computers/Programming/Languages/Fortran/Tools/
> , there are links to several sites with programs that create make files:
>
> Fmkmf
> http://www.met.ed.ac.uk/~hcp/fmkmf.html
> GNU Make Variables and Pattern Rules
> http://www.theochem.uwa.edu.au/fortran/make_variables/
>
> Makemake
> http://www.fortran.com/fortran/makemake.perl
>
> Perl scripts for Fortran
> http://www.arsc.edu/~kate/Perl/

and:

http://www.helsinki.fi/~eedelman/makedepf90.html

Regards,
B52B

Paul Van Delst

unread,
Nov 29, 2004, 10:46:10 AM11/29/04
to
Charles Russell wrote:
> "Richard Maine" wrote
>
>
>>current practice has been converging (on)
>>a defacto standard.
>
>
> Good. I can wait.

Hmm - I use the exact same makefiles to compile f90/95 code under linux
(ifort/pgf90/lf95/g95), IBM-AIX (xlf95), SGI-IRIX (f90), and Sun-Solaris (f95). All my
dependencies work with the source code (.f90 files) and the object files (.o). The module
files created -- be they .m, .MOD, .mod, or any other variants -- are included as required
since they are in the current directory or in the path defined by the ubiquitous -I
compiler switch.

<aside>
The only exception in my case is the Sun platform I use since the Sun compiler/linker
requires the "module include" switch to be -M. Argh. I hope they change that eventually,
but even that can be gotten around via a slightly more flexible make macro file. (Although
my dilemma is soon to become moot since the last few Sun machines I have access to are
being sunsetted since the licensing has become horrendously expensive for some reason :o()
</aside>

I realise my experience in this regard doesn't negate your concerns, but I've found the
make utility -- as hair-tear-out-ingly frustrating as it can be -- is pretty flexible and
quite portable (with some effort).

> I quickly abandoned Lahey because of its abysmal performance with bounds
> check enabled

Not related to the original thread, but you only use bounds-checking switches when you're
testing the code, right? Not when you're using it for production work?

FWIW, Lahey isn't the only compiler where performance suffers with bounds-checking
enabled. I've come to expect it -- and once I've debugged and unit tested all the code, I
turn it off. Nice and fast then. :o)

Richard E Maine

unread,
Nov 29, 2004, 12:43:28 PM11/29/04
to
I don't have the time (inclination?) to give an answer as thorough
as would be appropriate. I'm just going to briefly touch on one or
two aspects of your questions that I have specific brief comments
on, ignoring the rest. Apologies in advance for that. It doesn't
mean that I don't think the other parts are good questions. Perhaps
it even means that I think the parts I didn't answer are better
questions in that they are deeper than I can go right now. :-(

Ron Shepard <ron-s...@NOSPAM.comcast.net> writes:

> I'm assuming in a large project that source code is spread across
> several directories, and both object libraries and module files need
> to be shared among the various directories.
>
> One choice to be made is whether and how to group the module files

> into a single directory....

As an aside, I consider this more fundamental than a makefile question.
Ideally, one would make decisions like this first, independent of
any make-related questions. Than one figures out how to make make
do what you want, only revisiting the original decision if it seems
to be causing unreasonable problems in the makefile.

> Another option would be to create the module files in the original
> source code directories, and then figure out some way to move them
> to the "$(PROJECT)/modules" directory.

That's what I do. It is directly parallel to what I do for object
files. They also get made in the source directory and then moved
to the final installed location (usually as library files, but that's
a lower-level detail).

The main reason is to completely separate the build procedure from
the installed stuff. If I've made a change to something, I don't want
the installed stuff to reflect the change until the revised code
at least sucessfully compiles. That's true even for the temporary
installs in my test/development areas. It doesn't have to be done this
way, of course, but I just like the clean separation; I'm not sure
I could give you a strong objective defense.

And in both cases (object libraries and module information files),
I certainly wouldn't even consider making the poor users have to
list as many -I (or -M) directories as I have source directories.
The stuff I work on most often is of pretty modest size by today's
standards. I *ONLY* have the source in about one or two dozen
directories. But that's still an order of magnitude too many for
me to have to tell a user of the libraries about. Throwing all of
my source into one or two directories isn't acceptable either; I
hope I don't have to justify that one.

So a short summary of my reasons is being parallel with object file
treatment, separating installed copies from the build areas, and
simplifying the interface for the users of my libraries.

B52B gave a pointer to makedepf90. I use that and find it reasonably
well suited to my needs. There are several other tools for makefile
dependency generation. It has been a while since I made the choice,
so I forget the details, but it seems to me that one of the major
factors was that it dealt with multi-directory projects in a manner
that was well matched to the way I was organizing them. I'll also
note that my dependencies don't change nearly as much as the code
does; presumably this pattern is common.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Charles Russell

unread,
Nov 29, 2004, 2:45:42 PM11/29/04
to

"Paul Van Delst" wrote

> Hmm - I use the exact same makefiles to compile f90/95 code under linux
> (ifort/pgf90/lf95/g95), IBM-AIX (xlf95), SGI-IRIX (f90), and Sun-Solaris
> (f95). All my dependencies work with the source code (.f90 files) and the
> object files (.o). The module files created -- be they .m, .MOD, .mod, or
> any other variants -- are included as required since they are in the
> current directory or in the path defined by the ubiquitous -I compiler
> switch.

Good. Though actually I have little reason to use modules. My uses of
COMMON are few and simple, and do not get me into trouble. I might try
modules to avoid the risk of name space conflicts in library code, depending
on how much it costs me in turnaround to give up independent compiling and
linking of the library components. Makefile problems are thus a potential
hassle with little potential gain.

>you only use bounds-checking switches when you're testing the code, right?
>Not when you're using it for production work?

I don't do "production work." . I just want an answer for my own use, and
one successful run will suffice. My "user interface" is to edit the source
code, so I never want to leave debugging mode


Joost VandeVondele

unread,
Nov 29, 2004, 3:51:14 PM11/29/04
to
To me it seems that all these programs basically list the 'USEd'
module. However, I have the feeling this is not enough.. and will lead
to problems e.g. (each module a different file):

MODULE M1
TYPE T1
INTEGER :: I
END TYPE T1
END MODULE M1

MODULE M2
USE M1
TYPE T2
TYPE(T1) :: D1
END TYPE
END MODULE M2

MODULE M3
USE M2
CONTAINS
SUBROUTINE zero(D2)
TYPE(T2) :: D2
D2%D1%I=0
END SUBROUTINE zero
END MODULE M3

if dependencies of M3 are only M2, I suppose that things will be
miscompiled if T1 is changed (say INTEGER :: I -> CHARACTER(LEN=1) ::
I will still build OK). Is any of the listed tools able to detect this
and would it include M1 in the dependency list of M3 ?

Joost

Richard E Maine

unread,
Nov 29, 2004, 5:31:44 PM11/29/04
to
jv...@cam.ac.uk (Joost VandeVondele) writes:

[code elided]

> if dependencies of M3 are only M2, I suppose that things will be
> miscompiled if T1 is changed (say INTEGER :: I -> CHARACTER(LEN=1) ::
> I will still build OK). Is any of the listed tools able to detect this
> and would it include M1 in the dependency list of M3 ?

I see no reason why this would be a problem. M1 is a dependency of M2.
Make is designed to work with dependency trees like that. you don't
need to make an explicit dependency of M3 on M1. It should just work.
For all of make's idiosyncracies. I don't think it has a problem
there. This issue is not at all new to modules; make has been dealing
with such things as long as there has been a make.

Now if you want the dependency tree to be expanded for some other reason,
that's another matter. But it shouldn't be needed for make.

Joost VandeVondele

unread,
Nov 30, 2004, 4:33:23 AM11/30/04
to
> I see no reason why this would be a problem. M1 is a dependency of M2.
> Make is designed to work with dependency trees like that. you don't
> need to make an explicit dependency of M3 on M1. It should just work.

Ok, I see where my misunderstanding comes from. In my project, we do
the dependency using the .mod files (not .o) and only recompile if
these mod files change (we actually build .int files ourselves to work
around timestaps in .mod files) and this is wrong. I.e. M3 needs to be
recompiled even if M2.mod stays the same but M1.mod changes. (It is
obvious that we're trying to avoid recompiling the full project for
every change we make, but our solution is not yet correct).

Joost

Pierre Asselin

unread,
Nov 30, 2004, 8:58:26 AM11/30/04
to
Joost VandeVondele <jv...@cam.ac.uk> wrote:

> Ok, I see where my misunderstanding comes from. In my project, we do
> the dependency using the .mod files (not .o) and only recompile if
> these mod files change (we actually build .int files ourselves to work
> around timestaps in .mod files) and this is wrong. I.e. M3 needs to be
> recompiled even if M2.mod stays the same but M1.mod changes.

What's the issue ? In your example,
M1.o, M1.mod depend on M1.f90
M2.o, M2.mod depend on M2.f90, M1.mod
M3.o, M3.mod depend on M3.f90, M2.mod

The transitive closure has arcs from M3.o, M3.mod to M1.f90 , so
If you touch M1.f90, everything gets recompiled. Is there another way?

This scheme suffers from the recompilation cascade, where you change
the implementation but not the interface of M1.f90, i.e. the change
modifies M1.o but gives back the same M1.mod . The above dependencies
trigger unnecessary recompilations of M2 and M3. It's fail-safe
but burdensome. Again, is there another way ?

--
pa at panix dot com

Joost VandeVondele

unread,
Nov 30, 2004, 1:29:51 PM11/30/04
to
p...@see.signature.invalid (Pierre Asselin) wrote in message news:<cohua2$h7s$1...@reader1.panix.com>...

I understand (now) that the tools listed before give you the right
dependencies, and there is nothing that can go wrong. As I tried to
explain iin the second post, in our project we try to avoid the
recompilation cascades by generating first the interfaces (.int) of
all changed files, however, interfaces will only be touched if they
are actually different from what we had before. .o depends on the .int
of the USEd modules. This correctly avoids recompilation cascades if
only the implementation is changed.

In the above example, M1.int, M2.int, M3.int will be automatically
created and dependencies will be
M3.o : M2.int
M2.o : M1.int
The point is now that, even though M2.f90 is unchanged (and thus
M2.int is unchanged) M3.f90 needs recompilation if a change is made to
M1.f90 that affects its interface (since M1 is implicitly used by M3).
I'm not the makefile expert, but if you wish, you can have a look at
(http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cp2k/cp2k/makefiles/Makefile).

Joost

Richard E Maine

unread,
Nov 30, 2004, 2:02:53 PM11/30/04
to
jv...@cam.ac.uk (Joost VandeVondele) writes:

> I understand (now) that the tools listed before give you the right
> dependencies, and there is nothing that can go wrong.

I wouldn't say that "nothing can go wrong." :-) But this shouldn't.

> in our project we try to avoid the
> recompilation cascades by generating first the interfaces (.int) of
> all changed files, however, interfaces will only be touched if they

> are actually different from what we had before....

Sounds to me like what I'd call a bug in the tool you are using to
decide whether the .int files are changed, then. If the .int
for M2 depends on that of M1, then it seems that it should count as
being changed, and thus should be rewritten if the .int for M1 has
changed.

Tobias Schl?ter

unread,
Nov 30, 2004, 2:48:17 PM11/30/04
to
"beli...@aol.com" <beli...@127.0.0.1:7501> wrote in message news:<41a67...@127.0.0.1>...

> I don't expect for-profit companies to advertise their competitors. Gfortran
> is a commendable volunteer effort to benefit the Fortran community, and one
> way they can do this is by recommending that users also install g95 when
> it better suits their needs.

Unfortunately, using g95 can induce severe legal problems, given that
they way it's being published violates gcc's license (the GPL),
therefore there's no point in advertising it in an official project by
the FSF, as distributing it is not allowed. (Also, g95's library is
under the GPL, making it illegal to distribute non-GPL libraries that
are precompiled by g95, but the same is true for gfortran currently.
Fortunately, moves with the FSF have been made to remedy that
situation for gfortran [Toon, where's your patch? :-])

Were g95 developed according to the rules set by copyright law and gcc
(and not only using its code and some of its infrastructure), every
advance in g95 could also find its way into gfortran, and there would
be no need for two separate projects.

Regards,
- Tobias Schlüter

ps for everybody fond of disclaimers: I'm not a lawyer -- take this
cum grano salis, not as legal advice.

Toon Moene

unread,
Nov 30, 2004, 5:48:43 PM11/30/04
to
Tobias Schl?ter wrote:

> Unfortunately, using g95 can induce severe legal problems, given that
> they way it's being published violates gcc's license (the GPL),
> therefore there's no point in advertising it in an official project by
> the FSF, as distributing it is not allowed. (Also, g95's library is
> under the GPL, making it illegal to distribute non-GPL libraries that
> are precompiled by g95, but the same is true for gfortran currently.
> Fortunately, moves with the FSF have been made to remedy that
> situation for gfortran [Toon, where's your patch? :-])

Where's my time ? I know it is on my plate ...

> Were g95 developed according to the rules set by copyright law and gcc
> (and not only using its code and some of its infrastructure), every
> advance in g95 could also find its way into gfortran, and there would
> be no need for two separate projects.

Indeed.

> ps for everybody fond of disclaimers: I'm not a lawyer -- take this
> cum grano salis, not as legal advice.

But, on the other hand, I have discussed this matter on the GCC Steering
Committee mailing list with RMS and Eben Moglen (the FSF's legal
counsel) and their opinion was for the gfortran crowd to leave the g95
source alone.

Toon Moene

unread,
Nov 30, 2004, 6:13:30 PM11/30/04
to
Toon Moene wrote:

> Tobias Schl?ter wrote:

>> ps for everybody fond of disclaimers: I'm not a lawyer -- take this
>> cum grano salis, not as legal advice.

> But, on the other hand, I have discussed this matter on the GCC Steering
> Committee mailing list with RMS and Eben Moglen (the FSF's legal
> counsel) and their opinion was for the gfortran crowd to leave the g95
> source alone.

Reply to self: Don't rely on memory after midnight. What happened in
the discussion on the GCC Steering Committee mailing list was that I got
input from RMS, Jim Wilson (18+ years of experience on developing GCC)
and Jeff Law (release manager until GCC 2.95). It was Jim who advised
to stop following g95. However, as I know that Eben Moglen listens in
to this mailing list, this is about as good a legal advice as we can get.

Hope this helps,

Jan Vorbrüggen

unread,
Dec 1, 2004, 3:36:28 AM12/1/04
to
> In the above example, M1.int, M2.int, M3.int will be automatically
> created and dependencies will be
> M3.o : M2.int
> M2.o : M1.int

As Richard pointed out, you also need a rule stating that M2.int depends
on M1.int. If you add this, hey-presto everything will work properly.

Jan

Reply all
Reply to author
Forward
0 new messages