I'm always using free form .f90 to write Fortran code, but now I have to use some fixed form .f code. As far as I know, a line continuation in the fixed format can be achieved by putting an arbitrary nonblank, nonzero symbol in column 6.
So this first block should work
x =
& 1
and this second block would fail
x = &
& 1
I have the above conclusion proved by a simple demo code, both compiling with a Makefile and comping with Cmake. If using the first way, everything is good; if the second, compiler will report an error saying it can't understand the "&" after the equal sign.
Now what makes me puzzled is that I have a huge Fortran code in fixed form(.f) by someone else. What's used in this huge code for line continuation is like the second way(which seems not working to me). But the Makefile of that code managed to overcome this issue somehow. That code and Makefile is so large and complicated that I can't manage.
So my question is: How can I let the compiler go through the second way? What magic did the huge Fortran code do? Thanks for any hints.
Update:
I tried to use -ffree-form as suggested, but still get the same error. Here is the demo .f file and Makefile.
main.f
PROGRAM main
IMPLICIT NONE
REAL :: x
REAL :: y
x = &
& 1
WRITE(*,*) x
END PROGRAM main
Makefile:
FC = gfortran
FCFLAGS = -ffree-form
SRCS = main.f
SOBJ = $(SRCS:.f=.o)
EXEC = $(SRCS:.f=)
all: $(EXEC)
%.o: %.f
$(FC) $(FCFLAGS) -c $<
Related
It seems that OCaml runs some expressions at compile-time; e.g., if I write
let (_ : int) = 1 / 0
at the top level of a file, the compiler will fail with an "Uncaught exception: Division_by_zero" error.
Does this mean that these values are computed at compile time in the binary? e.g., if I was using Core, and I wrote
open! Core
let date = Date.today ~zone:(force Time.Zone.local)
would this refer to the date at the time of compilation, or something else, like the date when the program is executed?
I can't reproduce the behavior you describe. Here's what I see:
$ cat dz.ml
let (_ : int) = 1 / 0
$ ocamlc -c dz.ml
$ ocamlopt -c dz.ml
The two OCaml compilers are ocamlc and ocamlopt, and neither of them shows this behavior on my system.
It would help if you give a specific sequence of commands to reproduce what you observe.
I'm new to Eclipse. Despite its best efforts I got it to compile and run a
Hello World program. I am now trying to bring in a simple program I wrote that worked on MS Visual Studio 2010.
A user in reddit learnprogramming said I was missing a quotation mark in my make file, but I am using automatic make files. I don't know how to write my own and would rather work on the other 50 things wrong with the program. The Eclipse make file help page is technobabble to me.
I think Eclipse is not trying to build the files in the correct order, but I cannot find how to change the build order or how to point it towards the correct file to begin with. When I created the files in Eclipse, I hit "New Class" and then just copied and pasted in the old files. There are no red or yellow flags in the left margin indicating there are any problems. The file with the main method is Tier.cpp, but I believe it's trying to start with Player.cpp.
The compiler error is the very user friendly and easy to read:
01:31:42 **** Incremental Build of configuration Debug for project VanillaWoW ****
make all
Building file: ../VanillaWoWSource/Player.cpp
Invoking: Cross G++ Compiler
g++ -I"C:\cpp\boost_1_66_0\boost" -I"C:\cyg\bin"
-I"C:\cyg\lib\gcc\x86_64-pc-cygwin\6.4.0\include"
-I"C:\cyg\lib\gcc\x86_64-pc-cygwin\6.4.0\include\c++"
-I"C:\cyg\lib\gcc\x86_64-pc-cygwin\6.4.0\include\c++\backward"
-I"C:\cyg\lib\gcc\x86_64-pc-cygwin\6.4.0\include\c++\x86_64-pc-cygwin"
-I"C:\cyg\usr\include" -I"C:\cyg\usr\include\w32api"
-I"c:\cpp\boost_1_66_0\" -I"C:\cyg\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++"
-O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"VanillaWoWSource/Player.d"
-MT"VanillaWoWSource/Player.o"
-o "VanillaWoWSource/Player.o" "../VanillaWoWSource/Player.cpp"
/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [VanillaWoWSource/subdir.mk:26: VanillaWoWSource/Player.o] Error 1
I don't understand why it's throwing an error on line 26 of an object file that I didn't think it had fully even created yet. I don't know what /bin/sh: -c refers to, and I don't know which file it's hitting the end of file on.
Full code is at :
https://docs.google.com/document/d/185sOHxk3wKAnl6N0oCSvlJZB7WUTY8gEtZCsLIr1q0o/edit?usp=sharing
Now I formatted up your error messages, I can see the problem:
-I"c:\cpp\boost_1_66_0\" -I"C:\cyg\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++"
Note the boost_1_66_0\" - the trailing backslash escapes the quote character, so the text colouring goes wonky. Look where you set up paths and either remove the trailing backslash, or better, use forward slashes throughout. Windows will accept them, and you won't get bitten by mysterious escape problems.
I'm not sure why getting C++ set up is so difficult for you. It might have something to do with you using Eclipse -- it's really more of a Java IDE, and I'd suggest using something that's built for C++. When I was starting C++, I wrote with Code::Blocks and it worked great for me. I'd suggest switching to that.
C++ is a lower level language than Java. It's arguably more difficult to program in because of that. Although I do think the brunt of your issue is more because of the environment you're coding in.
I have a Fortran code that I have to run but unfortunately I don't have any experience with Fortran. I tried to run the code using different Fortran version and nothing works.
Here is the link for the code: http://cpc.cs.qub.ac.uk/summaries/adpw.
It would be great if someone could tell me which Fortran version should I use.
Here are the details:
When I try to run with gfortran:
gfortran numcbas.f < numcbas_c.data
Segmentation fault: 11
and when I run with g77:
g77 numcbas.f < numcbas_c.data
ld: warning: -macosx_version_min not specified, assuming 10.10
ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in __start from /usr/lib/crt1.o.
To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
And here is start of the code:
program NUMCBAS
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
MAIN DRIVING ROUTINE
CHARACTER*120 TITLE
DIMENSION IBUG(3),HRXS(10),IRXS(10)
COMMON /BASCON/ HRX(10),IRX(10),NIX,IRA
DATA TITLE /' '/
DATA HRXS/1.D-02,2.D-02,2.605D-02,7*0.D0/
DATA IRXS/30,120,500,7*0/,IBUG/3*0/
INTEGER :: NFTA=6,LUNUMB=13, LVAL=0
DOUBLE PRECISION :: BTOL=0.2D0, TINY=1.D-11
DOUBLE PRECISION :: ECMAX=10.D0, RLIM=10.D0, CHARGE=0.D0
NAMELIST /INPUT/ TITLE,LUNUMB,NIX,IRX,HRX,lval,IBUG,BTOL,
* TINY,ECMAX,RLIM,CHARGE
WRITE (6,1000)
and the input file:
&INPUT
TITLE='IONIC TARGET',
lval=0, ECMAX = 5.00D0,
RLIM = 12.0D0, CHARGE=1.0D0,/
It seems to me you are completely misunderstanding tho processes of compilation and running.
These lines are suspicious:
gfortran numcbas.f < numcbas_c.data
g77 numcbas.f < numcbas_c.data
There is no reason to redirect a data file to the compiler command. The compiler first has to create an executable program which you then can run with your data. Normally, a file ./a.out is created and you then run it
./a.out < some_data_to_stdin
It is very strange that you get a Segmentation fault from running gfortran without any other error message. Are you sure the commands you show above are exactly what you are running?
I've been working on a C++ application that embeds a prolog reasoning engine lately and, as stated in the title, I am now trying to generate a DLL instead of an executable so I can use it in another project. Since I am new to DLL development, I thought I could start with a small example. I have 3 files:
likes.pl: sample prolog file defining the predicate likes/2
likes.cpp: defining the function get_food() that calls PlQuery and return the results in a std::string
food.cpp: using the DLL to list all kinds of food that Sam likes
So my first try was the following:
swipl-ld -shared -dll -o likes -goal true likes.cpp likes.pl -DLIKES_EXPORTS -v
g++ -o food.exe -s food.cpp -L. -llikes -I. -L"c:/program files (x86)/swipl/lib" -lswipl -I"c:/program files (x86)/swipl/include"
First of all, let me point out that when get_food() only returns a string without any call to prolog, this works fine. However, after two days of investigation, I can't figure out how to get the DLL to call prolog. I think there are two things I am possibly doing wrong, maybe both: the PlEngine intialization and the saved state.
I've tried both calling PlEngine in get_food() and in food.cpp main() function, same result. So for now I am sticking to the first option since I am more interested in having everything done in the DLL. I see here (Embedding SWI-Prolog in a dll) that it can later be done in the DllMain but also that it is not recommended. What is the best way to do it? Should I give food.exe asargv[0] or something else (libswipl.dll? a saved state?)
Secondly, I noticed that one difference when using swipl-ld to generate a DLL instead of an EXE is that it ommits the lines:
swipl.exe -f none -F none -g true -t"consult(['likes.pl']),qsave_program('pltmp-4228.exe',[goal=true,toplevel=prolog,init_file=none])"
cat pltmp-4228.exe >> food.exe
So I tried to do it manually, replacing the random name by "mystate.exe" and using the Win32 copy /b command to append it to food.exe. This makes food.exe a toplevel console where I can test likes/2. Is it because the Dll doesn't have any main()? Anyway, this is the furthest I could get for now and I guess there were a few things to change in the qsave_program/2 second argument. I tried replacing toplevel=prolog with stand_alone=true. By the way, the command example given at the end of (http://www.swi-prolog.org/pldoc/doc_for?object=section%282,%272.10%27,swi%28%27/doc/Manual/compilation.html%27%29%29) doesn't generate any file at all. Anyway, I can't figure out if and how exactly I have to do this either.
Can anyone tell me how to solve this?
Forgive me, as this is not really a precise answer to your problem, just a report about my experience on the topic.
I've been working on pqConsole, a DLL that introduces Qt bindings via the C++ interface.
pqConsole, while still in development, has so far found its way in swipl-win, and I had the joy to work together with Jan Wielemaker making this little big step for Prolog audience widening.
I would suggest to build your DLL with G++, to get binary compatibility, and release SWI-Prolog component(s) as-is.
If you like Qt, you can use QtCreator for interface design, see for instance fdqueens.
There you can also see how I used to embed .pl in Qt project resources, to have more control about the application (users can't mess with the Prolog logic that's required from other parts) and over the release (no .pl to add, just the executable/DLL).
HTH
Solved it! In case somebody needs the answer someday:
int main(int argc, char *argv[]) {
char* av[50];
av[0] = (char*)"food.exe";
av[1] = (char*)"-x";
av[2] = (char*)"mystate.exe";
if(!PL_initialise(3, av))
cout << "NO init\n" ;
else
cout << "OK init\n" ;
cout << get_food() ;
getchar();
return 0;
}
Then:
swipl --goal=true --stand_alone=true -o mystate -c likes.pl
swipl-ld -shared -dll -o likes -goal true likes.cpp likes.pl -DLIKES_EXPORTS -v
g++ -o food.exe food.cpp -L"c:/program files (x86)/swipl/lib" -lswipl -I"c:/program files (x86)/swipl/include" -L. -llikes -I.
GDB is not showing me the line source after next/stop , and displays only line number and source file , like this :
(gdb) n
7 in test/test.c
whereas I expect it to display the current line , like this :
(gdb) next
17 char * good_message = "Hello, world.";
any settings in .gdbinit that might help me do this ?
whereas I expect it to display the current line , like this
On many platforms, such as ELF, the compiler records both the path to the source (test/test.c in your case), and the compilation directory, allowing GDB to display source regardless of which directory you invoke it in.
But many platforms are less flexible, and don't have a place to record compilation directory. On such platforms (e.g. AIX), you must either start GDB in the compilation directory, or tell it where to look for sources with directory command.
Probably my answer may not be a perfect solution but the way you compile your source program matters. For example in my case if you do g++ fib.cpp -o fib and then try to run gdb fib it won't print the source code with list. Using debug flag g++ -g fib.cpp -o fib and then running with gdb solved my problem.