Can't find libgfortran-3.dll in Fortran - dll

I am new to mingw32-gfortran, and I am finding it hard to statically link the specific dll's. I am trying to write a code on finding large factorials,the code compiles without any errors on code::blocks but gives an error about missing dll's when opened from cmd. Is there anyway to statically link these dll's to my exe (I don't mind if it is bloated,I just want my code to be portable).
Does gfortran provide similar libraries for static linking? I have also posted my code for any reference. It would really mean much to me if someone here helped me out, I have already tried code blocks forums,and read numerous posts on other websites. Still no luck.
Note : I use Win 7 64-bit
! A fortran95 program for G95
! By WQY
program main
implicit none
integer ,allocatable,dimension (:) :: a
integer :: re_i,n,digit=1,temp=0,zero=0,i,j,beg,rate,ends
allocate(a(10000000))
a(1)=1
print*,'please enter the number'
read *, n
call system_clock(beg,rate)
do j=2,n
do i=zero+1,digit
temp=temp+a(i)*j
a(i)=temp-(temp/10)*10
temp=temp/10
end do
do while (temp>0)
digit=digit+1
a(digit) = temp-(temp/10)*10
temp = (temp/10)
end do
do while(a(zero+1)==0)
zero=zero+1
end do
end do
call system_clock(ends,rate)
write(*,1,advance='no') a(digit)
write (*,2,advance ='no') '.'
write (*,1) ( a(i),i=digit-1,digit-50,-1)
1 format(120i1)
print *,' X 10^' ,digit-1
2 format(100a1)
print '("computation time ",f6.3," seconds")',real(ends-beg)/real(rate)
re_i=system("pause")
end
Does anyone know how to compile a program in gfortan from command line? Errors seems to pop up every time I try to do so.

Related

How do I tell Octave where to find functions without picking up other files?

I've written an octave script, hello.m, which calls subfunc.m, and which takes a single input file, a command line argument, data.txt, which it loads with load(argv(){1}).
If I put all three files in the same directory, and call it like
./hello.m data.txt
then all is well.
But if I've got another data.txt in another directory, and I want to run my script on it, and I call
../helloscript/hello.m data.txt
this fails because hello.m can't find subfunc.m.
If I call
octave --path "../helloscript" ../helloscript/hello.m data.txt
then that seems to work fine.
The problem is that if I don't have a data.txt in the directory, then the script will pick up any data.txt that is lying around in ../helloscript.
This seems a bit fragile. Is there any way to tell octave, preferably in the script itself, to get subfunctions from the same directory as the script, but to get everything else relative to the current directory.
The best robust solution I can think of at the moment is to inline the subfunction in the script, which is a bit nasty.
Is there a good way to do this, or is it just a thorny problem that will cause occasional hard to find problems and can't be avoided?
Is this in fact just a general problem with scripting languages that I've just never noticed before? How does e.g. python deal with it?
It seems like there should be some sort of library-load-path that can be set without altering the data-load-path.
Adding all your subfunctions to your program file is not nasty at all. Why would you think so? It is perfectly normal to have function definitions in your script. The only language I know that does not do this is Matlab but that's just braindead.
The other alternative you have is to check that the input file argument, data.txt exists. Like so:
fpath = argv (){1};
[info, err, msg] = stat (fpath);
if (err)
error ("could not stat `%s' : %s", fpath, msg);
endif
## continue your script knowing the file exists
But really, I would recommend you to use both. Add your subfunctions in your main program, the only reason to have it on separate file is if you plan on sharing with other programs, and always check input arguments.

Accessing files using MPI

THIS WORKED (see comment in the code)
I am new to MPI and still learning it. I am actually trying to write a code in Fortran to read data from same set of files (already generated) on each processor at same time and perform different computations in different processors. For which I decided to use,
program...
use mpi
implicit none
.
.
.
call mpi_file_open(mpi_comm_world,filename_i,mpi_mode_rdonly,mpi_info_null,i,ierr)
to start with the program. Now, each processor calls a subroutine in which I am trying to use normal fortran command to open files, open(i,*)...(since I don't use mpi in subroutine).
First, I am not confident about this idea itself. Next, it gives this error,
_open(mpi_comm_world,filename_i,mpi_mode_rdonly,mpi_status_ignore,i,ierr) (1)
Error: There is no specific subroutine for the generic 'mpi_file_open'
at (1)
Please give your suggestions and comments.
The thing I am trying to do is very long because of subroutine, I would just include a prototype code, if this is solved, my problem will be solved. The code below gives the same error as said before. Please give your suggestions. Thanks.
program hello
use mpi
integer::ierr,num_procs,my_id,i,j,no
call MPI_INIT(ierr)
call MPI_COMM_RANK (MPI_COMM_WORLD,my_id,ierr)
call MPI_COMM_SIZE (MPI_COMM_WORLD,num_size,ierr)
open(4,file='hella') !CHANGING THIS LINE
do i=1,num_size
if(i-1 .eq. my_id)print*,"In",my_id
if(i-1 .eq. my_id)then
read(4,*)no
print*,no
endif
enddo
call mpi_finalize(ierr)
end program hello

Trying to read in a .gda file to IDL

I am trying to read in a .gda file into IDL for plotting purposes. I am not familiar with the format and my research indicates it is an unformatted binary data file type. Anyways, here is what I am doing:
pro omidi_contour
openr, 1, 'data.gda'
a = fltarr(128,128,128)
readu, 1, a
close, 1
end
However when I look at the variable definition at the left panel of IDL, it indicates that a is 'undefined'. When I try to print:
print, a[0,0,0]
I get:
Variable is undefined: A
How can I solve this?
I found out that there was nothing wrong with my program. It was reading the right values from the file. However, the IDL "forgot" the value of the variables once the program was done. Solution: DO not run this as a program i.e. remove the following lines:
pro omidi_contour
end
This makes the code to run as if each line were typed into the IDL prompt and IDL does remember the values this time round.

Integer variable no longer usable after forall construct

I have an integer variable that is declared at the head of my subroutine. After I've used it as a control variable inside a forall construct, I can no longer use it as the control variable of a do loop. The compiler (Intel, v. 12.0.3) complains
xyz.f90(1210): error #6404: This name does not have a type, and must have an explicit type. [I]
do i=1,sp_basis%num_dim
---------------^
xyz.f90(1210): error #6063: An INTEGER or REAL data type is required in this context. [I]
do i=1,sp_basis%num_dim
I have tried to write a small example to replicate this behaviour (and compiled the file with the same compiler options as the actual problematic one, apart from -c), but this compiled & worked nicely, so below is my (slightly shortened) problematic code (implicit none applies to the entire module this code belongs to):
subroutine xyz(stuff)
use data, only: ppm, npeaks
! some declarations
integer :: i ! ...
associate(sp_basis => public_spectra%basis(counter))
spots = npeaks * np
allocate(ref_curves(spots,npeaks,sp_basis%num_dim), stat=stat)
if (stat.ne.0) then
! ...
end if
forall (i=1:max_dim) uppers(i) = ubound(sp_int%int,i)
forall (i=1:max_dim) lowers(i) = lbound(sp_int%int,i)
forall (i=1:npeaks,j=1:sp_basis%num_dim) peak_pos_hertz(j,i) = ppm_to_hertz(ppm(permutation(j),i), sp_axes(j))
do peak_considered=1,npeaks
do pos=(peak_considered-1)*np+1,peak_considered*np
do i=1,sp_basis%num_dim ! <-- COMPLAINT
If I change i to a name that was not used as a forall construct's control variable everything works. Also, this is the second time I've run into this problem.
This is how the compilation is done (xyz.f90 is one of many files that make up the entire program):
ifort -c -g -C -check noarg_temp_created -traceback -warn -warn nodeclarations -nogen-interface xyz.f90
Does any of you know what the problem might be?
Thanks a lot for your time!
For all those interested, it's a bug in the Intel compiler. Here you can read more about it. Also it sounds like this bug will be fixed in a compiler version that is to be released some time in 2012.

program to reproduce itself and be useful -- not a quine

I have a program which performs a useful task. Now I want to produce the plain-text source code when the compiled executable runs, in addition to performing the original task. This is not a quine, but is probably related.
This capability would be useful in general, but my specific program is written in Fortran 90 and uses Mako Templates. When compiled it has access to the original source code files, but I want to be able to ensure that the source exists when a user runs the executable.
Is this possible to accomplish?
Here is an example of a simple Fortran 90 which does a simple task.
program exampl
implicit none
write(*,*) 'this is my useful output'
end program exampl
Can this program be modified such that it performs the same task (outputs a string when compiled) and outputs a Fortran 90 text file containing the source?
Thanks in advance
It's been so long since I have touched Fortran (and I've never dealt with Fortran 90) that I'm not certain but I see a basic approach that should work so long as the language supports string literals in the code.
Include your entire program inside itself in a block of literals. Obviously you can't include the literals within this, instead you need some sort of token that tells your program to include the block of literals.
Obviously this means you have two copies of the source, one inside the other. As this is ugly I wouldn't do it that way, but rather store your source with the include_me token in it and run it through a program that builds the nested files before you compile it. Note that this program will share a decent amount of code with the routine that recreates the code from the block of literals. If you're going to go this route I would also make the program spit out the source for this program so whoever is trying to modify the files doesn't need to deal with the two copies.
My original program (see question) is edited: add an include statement
Call this file "exampl.f90"
program exampl
implicit none
write(*,*) "this is my useful output"
open(unit=2,file="exampl_out.f90")
include "exampl_source.f90"
close(2)
end program exampl
Then another program (written in Python in this case) reads that source
import os
f=open('exampl.f90') # read in exampl.f90
g=open('exampl_source.f90','w') # and replace each line with write(*,*) 'line'
for line in f:
#print 'write(2,*) \''+line.rstrip()+'\'\n',
g.write('write(2,*) \''+line.rstrip()+'\'\n')
f.close
g.close
# then complie exampl.f90 (which includes exampl_source.f90)
os.system('gfortran exampl.f90')
os.system('/bin/rm exampl_source.f90')
Running this python script produces an executable. When the executable is run, it performs the original task AND prints the source code.