forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

gFortran and MAKE
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri May 10, 2019 2:21 pm    Post subject: gFortran and MAKE Reply with quote

I have the code which was made in gFortran which FTN95 was unable to compile due to conflict in common block or possible error. Fun is that conflicting variable is just 1 symbol long. The authors of the code are not responding hence there are two options: to find what for this variable was used in the code or to use gFortran and let it compile the code as is. Code is very large, so it was not easy to find the purpose of this variable. So i decided to try gFortran to compile this code. The ability of FTN95 to catch the bugs like a terminator became its Achilles heel. While gFortran makes executable like crazy despite of gazillion of errors in the source code. But unfortunately this code uses MAKE utility i am not familiar with at all.

My questions are:

1) Do anyone has the experience with MAKE utility used for compilation with gFortran? The MAKE file has options for all Fortran compilers in the world since Roman Empire, кроме FTN95, so i get sick after 3 minutes trying to decipher what is what there.

2) What source to download gFortran compiler do you recommend?

3) How to install gFortran without any potential conflicts with FTN95?


Last edited by DanRRight on Sat May 11, 2019 12:57 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri May 10, 2019 7:11 pm    Post subject: Reply with quote

Dan, I think that for running Gfortran the easiest way is to find a Linux system with Gfortran installed on it. A Linux VM on Windows will do almost as well.

You can obtain Gfortran for Windows from equation.com, Lahey, and with various Mingw distributions. These distributions also provide make Note that these distributions provide the compiler and tools for command line usage. If you want a GUI for building, you have to choose and install one yourself.

FTN95 comes with its own make utility, mk32. In many cases, the use of make is not really needed; just compile all the Fortran source files and link them together. In more complicated cases, the Fortran sources may need some kind of preprocessing, and it may be necessary to compile some C sources in addition and link the resulting object files together with some libraries.

Perhaps, if you can post the declarations of the variables in the offending common block and what FTN95 says about the code, we can help. Similarly, if you can post the makefile here, some helpful comments may be made.

As far as
Quote:
3) How to install gFortran without any potential conflicts with FTN95?
is concerned, there is nothing to worry about.

Last edited by mecej4 on Thu May 16, 2019 9:34 am; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun May 12, 2019 8:34 pm    Post subject: Reply with quote

Dan, MAKE's a bit of an enigma from what little I've read up on it.

As you said mecej4 it's no better in principal then writing a script file to execute a sequence of compile/link commands.

And it appears to be more idiot-syncratic in that some commenììands you write and it 'deduces' what files you want to compile/link based on it's internal algorithm.

If I understand correctly it's geared at creating for multi-platform useage.

There's also a really wise wise-noy out there on the market called CMAKE I believe.

I came across it when trying to get to use PGPLOT for plotting.
You need it to compile their progrom from source (for some odd reason they don't have a ìn FTN95 binary available.
Of course ftn95 doesn't support CMAKE so it can't be used.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Mon May 13, 2019 12:30 pm    Post subject: Reply with quote

Hello,

I used the make utility on UNIX systems in former times and did not think it was an enigma Wink

In bigger projects you defined relations between sources and objects to be created in so called Makefiles. Instead of calling scripts or batch files you called the make utility with special parameters in order to create the objects. One of these parameters could be the name of the object you wanted to create. (This is only roughly spoken).

The make utility checked which objects were out of date (this depends on the relations defined in the Makefile mentioned above) and executed the commands to create them (which are defined in the Makefile, as well).

You should keep in mind that in the former times studios were not at hand.

If you use scripts or batch files no check is done if files to be created are out of date. This is a big difference when using make as opposed to scripts or batches.

If you create libraries e.g. depending on more than 1 fortran source file then in a batch file you would create the object files from all the source files involved and then archive them into a library. If some of the object files are not out of date the compile step for creating these object file would not be necessary.

There is an option of the make utility (-n), which shows what make would execute (if called without option -n) which I found very handsome.

As far as I know some of the studios have options to create the corresponding Makefiles for the projects.

I do not know if the Makefiles on UNIX and Windows/gfortran differ very much but I would suspect not.

By the way I just have in mind that the use of TABs were important for the rules defining how an object was created from a source file (which often is the complete compile command with all its options).

Regards,
Dietmar
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue May 14, 2019 4:10 pm    Post subject: Reply with quote

... maybe I meant enema ! Wink
... as in will MAKE turn out to be not so much a friend as an enema ! Wink

It's like all these clever things I guess, if you have the time and the inclination and the patience to learn it's idiotsyncracies, it can be very useful.

And like riding a bicycle, once you've learned you never forget (usually because of all the times you fall off before cracking it ! LOL

I'm of the old school who likes to see the whole process written down (a script) so the thought of using something which works somewhat blindly (to the user) in picking up files as you descrìbe well, is somewhat preoccupying.

I found a good description (by example) which unfortunately I didn't save the link to because I got caught up in that Firefox screw-up with add-ons 10 days ago which has resulted in me having to install the latest version. As a result of which I lose the ability to use my favouite session manager (called 'Session Manager').
As a result of shich I'm mìnow struggling with soem inferior upstart of an alternative.

I'll try to dig out the link to the description I saw.

I guess that'0s also part of the problem, like many a thing, finding a really good description of what MAKE is and how it works.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed May 15, 2019 12:22 pm    Post subject: Reply with quote

Apologies for being dim, but isn't the point of compiler error messages that you can go away and resolve the problem in the Fortran source code, not to change your compiler? (Unless, of course, the error message was bogus). Surely the error message points you (not always accurately) to the issue at hand?

Code:
Error No. XYZ1234 This compiler can't handle the following line of code. Use Gee Fort instead.

Unbelievable!

It's far more difficult to resolve a problem for which no error message is emitted, like those programs that predict the end of the world just because I drove to the supermarket in a diesel car and carried my shopping home in a plastic bag, instead of walking with a basket made of reclaimed newspapers on my head.

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed May 15, 2019 2:06 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
... isn't the point of compiler error messages that you can go away and resolve the problem in the Fortran source code, not to change your compiler? (Unless, of course, the error message was bogus).


It is not unusual to be in a situation where the code being worked on uses, say, F2003 features that are supported by Compiler A, and is beset by bugs that compiler B is better at catching, but compiler B only supports F95. Compiler A is not as good at catching errors. Compiler B, when it sees F2003 features that it does not understand, is likely to issue many error messages.

There is no obvious choice here.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed May 15, 2019 5:43 pm    Post subject: Reply with quote

Mecej4,

If it's a large, pre-existing code, then it's unlikely to use modern features. If it does, then they are the very things most likely to cause problems! Dan seems to have a problem caught by FTN95 that the other compiler ignores. Is that truly a good reason to wrestle with the other compiler? I didn't get the impression that there were many error messages. He didn't say that it was an unsupported feature in FTN95 that caused the problem - and indeed, the code he has to wrestle with might have been emitting wrong results for years or even decades - I know of examples.

Most of the other compilers don't have inbuilt graphics, or tools to build GUIs - or at least not unless one wants to spend a lot of money on third-party add-ons. Some of us think that they are more important than the latest gizmos even if those gizmos are indispensable to others. That pretty much makes using the alternative to FTN95 out of the question as far as I am concerned.

Perhaps it's my good fortune to only ever need to work on Fortran that I wrote myself. Just about everything I've seen written by anybody else might just as well be in Klingon*. I put that down to only programming as a side interest as well as having a pedestrian and old-fashioned style, I am reminded of the notorious quote that it is possible to write Fortran in any language!

Eddie

*Just like the BMW factory doesn't seem to put indicators on its cars, or at least, their drivers cannot find the switch, many Fortran programmers seem to be unaware of how useful comments can be. Ally this to a preference for statement numbers chosen at random, and Cotton-eyed Joe structures if they eschew statement numbers, then the incomprehensibility is not difficult to explain.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu May 16, 2019 8:11 pm    Post subject: Reply with quote

Dan wrote originally:
Quote:
I have the code which was made in gFortran which FTN95 was unable to compile due to conflict in common block or possible error


Dan, maybe the best bet to start ìs to post what error , or other,messages you get from the ftn95 compile attempt and what makes you think it might be a Common Block problem.

As for gfortran, and following mecej4's suggestion, try this binary for gfortran install:
https://www.fortran.com/wp-content/uploads/2013/05/g95-Mingw_201210.exe
(which is obtained from here:-
https://www.fortran.com/the-fortran-company-homepage/whats-new/g95-windows-download/ )

It must be said that it's a tortuous path to find a link going either through the sourceforge sites or other.
They don't make it easy do they.

-----

Eddie, as for your BMW indicators conundrum (*) , maybe it's for the same incomprehensible reason that all BMW's do not have Reg. GAE ? Smile or why car glass unanimously promote their cars Smile

(*) which I can confirm from past experience extends to all vehicles which circulate on the Turin ring road in Italy Smile
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu May 16, 2019 11:43 pm    Post subject: Reply with quote

The link that John S. gave is for G95, not Gfortran.

G95 is outdated and lacks many of the Fortran 2003 and 2008 features that are present in Gfortran. G95 does not support X64 on Windows, and may have some incompatibilities with Windows 10. Gfortran was forked from G95 in 2003.

Gfortran has many authors, whereas G95 has essentially one (he did a beautiful job back then, but ...).
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu May 23, 2019 6:28 am    Post subject: Reply with quote

Dan,

I have abandoned use of make and now use "simple" .bat files to control compile and load, using either:
slink64 @load_list.txt >> ftn95.tce
or
gfortran @load_gf.txt >> gf_build.tce 2>&1

With this approach, I can define local environment variables for different compilation options for groups of .f90 files and do a rebuild, eg optimisation or stack size selection.
slink64 Ver 8.05 certainly encouraged this approach when .lib files were not supported. (I am still using this approach, without yet going back to the .lib files)

The build times for my programs are now so quick that the faster MAKE strategies are no longer needed. Not even time for a coffee !

By using the following as the first two lines of my build .bat, there is no confusion with using incompatible .mod or .obj files.
del *.obj
del *.mod

It should not be too difficult to convert a make to a do_build.bat

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat May 25, 2019 8:16 am    Post subject: Reply with quote

Sorry, i had no time to clean the code from elementary errors FTN95 complaining due to different default TAB size of Gfortran and FTN95. Newer FTN95 probably already can handle different TAB sizes, but there was no time even to look how this works
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat May 25, 2019 2:09 pm    Post subject: Reply with quote

My understanding is the TAB is not part of the Fortran standard.
I do not know what interpretation ifort, gFortran or FTN95 apply to TAB, but it certainly is not portable.

There is also the issue of the possible different interpretation that FTN95 and Plato apply to TABS, as what you see may not be what you get.
In general, there is no guarantee that the representation of TAB characters by the IDE will be the same as the compiler interpretation. This has been shown in past posts reporting line length errors, either 72 or 132 length lines. Plato will allow you to change the tab settings which can make for strange errors when compiling with FTN95 !!

I would recommend scanning the source code for tabs and replacing them in a way that is compatible with the compiler that was used to develop the code.
If you are writing a scanner with FTN95, remember to use the subroutine READ_TABS@(unitno), to enable tabs to be identified.

gFortran has a compile option -Wtabs to help locate tabs in code. FTN95 should have the same.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat May 25, 2019 4:46 pm    Post subject: Reply with quote

Recent versions of FTN95 have the "/TABS n" command line option which allows you to change from the default tab size of 8.

Also recent versions of Plato automatically adds /TABS n to a command line and uses the a value for n that equals the current user tab setting.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun May 26, 2019 3:25 am    Post subject: Reply with quote

Paul,

Thanks for the update.

Definition of TAB interpretation is not easy to find. I could not find what gFortran does although I think it may be similar to iFort, which has the first tab to column 6 for F77 format. I am not sure what free format does.
(Could not find /TABS in ftn95.chm either)

Doesn't Plato has an option to replace all tabs with equivalent spaces when the file is saved ? (tools>settings>text editor) "Replace tabs with spaces" which could be a good thing for free format. This could cause a lot of problems if it was old fixed format code developed on ifort.
"Show whitespace symbols" is also very useful (which I always use, as with /IMPLICIT_NONE !!)

My preference is to not use the tab character in code.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group