I am under windows (as the obj extension shows).
I have two valid .f90 files A.f90 and B.f90 (placed in the same folder) provided to me, where B.f90 uses A.f90, the code of B.f90 being :
module B
use A
! ... stuff
The code of A.f90 is
module A
! ... stuff
I compile A.f90 with :
ifort -c -fpp A.f90
Now I would like to compile B.f90 "while taking accound of" A.f90, that is, of its .obj file.
So I tried :
ifort -c B.f90 A.obj
which throws
ifort: warning #10145: no action performed for file 'A.obj'
at me.
Is the command
ifort -c B.f90
proper to compile B.f90 "while taking accound of" A.f90, that is, of its .obj file ?
I would like B.f90 it to be compiled "as A.f90 is", as in fact I have a third C.f90 (containing a use B) and that at the end I must run the command :
ifort -dll toto.dll A.o B.o C.o
to compile a dll while linking to all object files from A, B, C.
The information about module A that the compiler needs in order to compile file B.f90 is not in file A.f90 but in file A.mod (name of the module followed by .mod extension). The default is that .mod files are created in and read from the directory where ifort is run from. Therefore, if you compile files in the right order (as you are doing), and run ifort from the same directory when you compile all these files, it will have access to the previously compiled module files, and everything will work fine with simple commands such as
ifort -c B.f90
If, at compilation time, a compiler does not have access to the module file of a module that is used in the file currently compiled, an error will be isued and compilation will abort.
Related
I've just inherited some C++ code that was written poorly with one cpp file which contained the main and a bunch of other functions. There are also .h files that contain classes and their function definitions.
Until now the program was compiled using the command g++ main.cpp. Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the g++ main.cpp command?
list all the other cpp files after main.cpp.
ie
g++ main.cpp other.cpp etc.cpp
and so on.
Or you can compile them all individually. You then link all the resulting ".o" files together.
To compile separately without linking you need to add -c option:
g++ -c myclass.cpp
g++ -c main.cpp
g++ myclass.o main.o
./a.out
Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the "g++ main.cpp" command?
Compiling several files at once is a poor choice if you are going to put that into the Makefile.
Normally in a Makefile (for GNU/Make), it should suffice to write that:
# "all" is the name of the default target, running "make" without params would use it
all: executable1
# for C++, replace CC (c compiler) with CXX (c++ compiler) which is used as default linker
CC=$(CXX)
# tell which files should be used, .cpp -> .o make would do automatically
executable1: file1.o file2.o
That way make would be properly recompiling only what needs to be recompiled. One can also add few tweaks to generate the header file dependencies - so that make would also properly rebuild what's need to be rebuilt due to the header file changes.
.h files will nothing to do with compiling ... you only care about cpp files... so type g++ filename1.cpp filename2.cpp main.cpp -o myprogram
means you are compiling each cpp files and then linked them together into myprgram.
then run your program ./myprogram
I know this question has been asked years ago but still wanted to share how I usually compile multiple c++ files.
Let's say you have 5 cpp files, all you have to do is use the * instead of typing each cpp files name E.g g++ -c *.cpp -o myprogram.
This will generate "myprogram"
run the program ./myprogram
that's all!!
The reason I'm using * is that what if you have 30 cpp files would you type all of them? or just use the * sign and save time :)
p.s Use this method only if you don't care about makefile.
You can still use g++ directly if you want:
g++ f1.cpp f2.cpp main.cpp
where f1.cpp and f2.cpp are the files with the functions in them. For details of how to use make to do the build, see the excellent GNU make documentation.
As rebenvp said I used:
g++ *.cpp -o output
And then do this for output:
./output
But a better solution is to use make file. Read here to know more about make files.
Also make sure that you have added the required .h files in the .cpp files.
You can use several g++ commands and then link, but the easiest is to use a traditional Makefile or some other build system: like Scons (which are often easier to set up than Makefiles).
If you want to use #include <myheader.hpp> inside your cpp files you can use:
g++ *.cpp -I. -o out
I used to use a custom Makefile that compiled all the files in current directory, but I had to copy it in every directory I needed it, everytime.
So I created my own tool - Universal Compiler which made the process much easier when compile many files.
You can do that using a single command assuming all the needed .cpp and .h files are in the same folder.
g++ *.cpp *.h -Wall && ./a.out
It will compile and execute at the same time.
when using compiler in the command line, you should take of the following:
you need not compile a header file, since header file gets substituted in the script where include directive is used.
you will require to compile and link the implementation and the script file.
for example let cow.h be header file and cow.cpp be implementation file and cow.cc(c++ files can have extension .cpp, .cc, .cxx, .C, .CPP, .cp) be script file.
Since gcc compiler notation for c++ file is g++, we can compile and link the files using
$g++ -g -Wall cow.cpp cow.cc -o cow.out
options '-g' and '-Wall' are for debugging info and getting warning for errors. Here cow.out is the name of the executable binary file that we can execute to run the program. it is always good to name your executable file otherwise name will be automatically given which might be confusing at times.
you can also do the same by using makefiles, makefiles will detect, compile and link automatically the specified files.
There are great resources for compilation using command line
enter link description here
~/In_ProjectDirectory $ g++ coordin_main.cpp coordin_func.cpp coordin.h
~/In_ProjectDirectory $ ./a.out
... Worked!!
Using Linux Mint with Geany IDE
When I saved each file to the same directory, one file was not saved correctly within the directory; the coordin.h file. So, rechecked and it was saved there as coordin.h, and not incorrectly as -> coordin.h.gch. The little stuff.
Arg!!
I am using Intel Pin to compile a C source and header file along with my c++ pintool. To do so I have added the following makefile rules in my makefile.rules file -
# Build the intermediate object file.
$(OBJDIR)testcpp$(OBJ_SUFFIX): testcpp.cpp
$(CXX) $(TOOL_CXXFLAGS_NOOPT) $(COMP_OBJ)$# $<
# Build the intermediate object file.
$(OBJDIR)test$(OBJ_SUFFIX): test.c test.h
$(CC) $(TOOL_CXXFLAGS) $(COMP_OBJ)$# $<
# Build the tool as a dll (shared object).
$(OBJDIR)testcpp$(PINTOOL_SUFFIX): $(OBJDIR)test$(OBJ_SUFFIX) test.h
$(LINKER) $(TOOL_LDFLAGS_NOOPT) $(LINK_EXE)$# $(^:%.h=) $(TOOL_LPATHS) $(TOOL_LIBS)
testcpp.cpp is my pintool in C++ , test.c and test.h are my C source and header files.
I am using the rules mentioned in this link - https://software.intel.com/sites/landingpage/pintool/docs/97438/Pin/html/index.html#MAKEFILES
I removed this option from the file makefile.unix.config -
TOOL_CXXFLAGS_NOOPT += -fno-rtti
as this option is specifically for C++ and C does not use it. Since I am compiling both of them using the same compiler options, removing the option seemed better than adding a new rule for C and C++
I am able to make my program using the command "make". It generated a directory obj-intel64 with the object files test.o and testcpp.so, so my compiling worked fine.
For executing my program I use the following command -
$PIN_ROOT/pin -t obj-intel64/testcpp.so -- my_application_program
I get the following output -
E: Unable to load obj-intel64/testcpp.so
The file testcpp.so is present in the obj-intel64 directory, yet I am unable to load it.
Any hints as to where I am going wrong?
I'm doing some experiment about extern keywork and currently working on Fedora 19 and g++.
Im trying to compile multiple c++ files and execute the program. Here it compiled successfully. but when try to run it shows Permission denied error. I change to permission using chmod to 777. but still result is same. then I try to compile and run a simple Hello World program and That works fine. Whats wrong with my program?
test1.h
int a=0;
test2.h
#include <iostream>
using namespace std;
extern int a;
void foo()
{
cout << "This is a test string " << endl;
cout << a << endl;
}
int main()
{
foo();
}
Here is how I compiled and the execute result of theTerminal
[root#localhost cpp]# g++ test1.h test2.h -o test.o
[root#localhost cpp]# ./test.o
bash: ./test.o: Permission denied
[root#localhost cpp]#
You have several problems. If you use the file(1) utility to inspect the output file, you'll realize why it can't be executed:
$ file test.o
test.o: GCC precompiled header (version 013) for C++
Precompiled header files are not valid executable files—they're not valid ELF files and they're not script files with a shbang line, they're just data files that the compiler knows how to read.
Why are you getting a precompiled header file? Because you're asking g++ to compile header files (.h files). It's really ridiculous to give your C++ source files .h extensions, because they're not header files, they're source files. Give them the proper .cc or .cpp extensions, and g++ will compile them correctly to an executable.
Secondly, why are you giving the output file the name test.o? .o is used for object files (compiled versions of singular source files, not complete executables), but you're asking g++ to compile a full executable. If you only want to compile and not also link, then pass the -c flag, and then manually link the object files together. Don't name your executables with .o. test would be the more proper name for an executable compiled from a source file named test.cc, but I'd caution against that and recommend using something else, because test is also the name of a shell builtin function.
When you compile .h files using g++, the compiler generates precompiled header files. These are not executable files. They won't run even if you changed their permissions to 777.
Look for This program is also useful when precompiling a C header file with a ‘.h’ extension for use in C++ compilations. at https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/Invoking-G_002b_002b.html#Invoking-G_002b_002b.
Try these commands:
g++ -o test.o test1.h
file test.o
You should get the output
test.o: GCC precompiled header (version 014) for C++
To create an executable, rename the files to test1.cc and test2.cc. Then, build the executable from them using
g++ -o test test1.cc test2.cc
Now, you will be able to execute the program using:
./test
Building modules in Fortran needs to be done in a specific order, e.g. if a file A.f needs module defined in B.f, then B.f needs to be compiled first. How can I impose such build order in Scons? If I provide it with a list of source files, it arranges them alphabetically (so A.f is compiled before B.f). I read about Requires() and Depends() functions, but wasn't able to get them to work for me.
I would be happy with just listing source files in order I need them compiled (so disabling reshuffling them in alphabetical order), but any other method would be welcomed as well.
As per Kyle's request, here's my Sconscript and a build log:
# Main program building script
Import('env')
PROGRAM = 'main.exe'
SRC_PREFIX = './src/'
SRC = [ 'array_1D_module.f',
'array_2D_module.f',
'array_3D_module.f',
'thomas_algorithm_module.f',
'histogram_module.f',
'histogram_computer_module.f',
'density_parameters_module.f',
'diffusion3D_aos_z_sub_solver_module.f',
'diffusion3D_aos_y_sub_solver_module.f',
'diffusion3D_aos_x_sub_solver_module.f',
'diffusion3D_aos_solver_module.f',
'nonlinear_diffusion_utilities_module.f',
'nonlinear_diffusion_parameters_module.f',
'derivative_magnitude_computer_module.f',
'nonlinear_diffusion_module.f',
'main_module.f',
'main.f' ]
# Attach prefix to each source file
for i in range( len(SRC) ) :
SRC[i] = SRC_PREFIX + SRC[i]
env.Program(target = PROGRAM, source = SRC)
This produced:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
ifort -o src/array_1D_module.o -c src/array_1D_module.f
ifort -o src/array_2D_module.o -c src/array_2D_module.f
ifort -o src/array_3D_module.o -c src/array_3D_module.f
ifort -o src/density_parameters_module.o -c src/density_parameters_module.f
ifort -o src/derivative_magnitude_computer_module.o -c src/derivative_magnitude_computer_module.f
ifort -o src/diffusion3D_aos_solver_module.o -c src/diffusion3D_aos_solver_module.f
src/diffusion3D_aos_solver_module.f(7): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [DIFFUSION3D_AOS_Z_SUB_SOLVER_MODULE]
use diffusion3D_aos_z_sub_solver_module, only :
------------^
So density_parameters_module.f was compiled before thomas_algorithm_module.f, even though it comes after it in my list.
Is your program (as suggested) using modules? There's a couple of gotchas there:
FORTRANMODDIR needs defining: See http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=82725 for a discussion on that.
I found that having source files containing a mixture of module definitions and source code caused a certain amount of confusion.
I've just inherited some C++ code that was written poorly with one cpp file which contained the main and a bunch of other functions. There are also .h files that contain classes and their function definitions.
Until now the program was compiled using the command g++ main.cpp. Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the g++ main.cpp command?
list all the other cpp files after main.cpp.
ie
g++ main.cpp other.cpp etc.cpp
and so on.
Or you can compile them all individually. You then link all the resulting ".o" files together.
To compile separately without linking you need to add -c option:
g++ -c myclass.cpp
g++ -c main.cpp
g++ myclass.o main.o
./a.out
Now that I've separated the classes to .h and .cpp files do I need to use a makefile or can I still use the "g++ main.cpp" command?
Compiling several files at once is a poor choice if you are going to put that into the Makefile.
Normally in a Makefile (for GNU/Make), it should suffice to write that:
# "all" is the name of the default target, running "make" without params would use it
all: executable1
# for C++, replace CC (c compiler) with CXX (c++ compiler) which is used as default linker
CC=$(CXX)
# tell which files should be used, .cpp -> .o make would do automatically
executable1: file1.o file2.o
That way make would be properly recompiling only what needs to be recompiled. One can also add few tweaks to generate the header file dependencies - so that make would also properly rebuild what's need to be rebuilt due to the header file changes.
.h files will nothing to do with compiling ... you only care about cpp files... so type g++ filename1.cpp filename2.cpp main.cpp -o myprogram
means you are compiling each cpp files and then linked them together into myprgram.
then run your program ./myprogram
I know this question has been asked years ago but still wanted to share how I usually compile multiple c++ files.
Let's say you have 5 cpp files, all you have to do is use the * instead of typing each cpp files name E.g g++ -c *.cpp -o myprogram.
This will generate "myprogram"
run the program ./myprogram
that's all!!
The reason I'm using * is that what if you have 30 cpp files would you type all of them? or just use the * sign and save time :)
p.s Use this method only if you don't care about makefile.
You can still use g++ directly if you want:
g++ f1.cpp f2.cpp main.cpp
where f1.cpp and f2.cpp are the files with the functions in them. For details of how to use make to do the build, see the excellent GNU make documentation.
As rebenvp said I used:
g++ *.cpp -o output
And then do this for output:
./output
But a better solution is to use make file. Read here to know more about make files.
Also make sure that you have added the required .h files in the .cpp files.
You can use several g++ commands and then link, but the easiest is to use a traditional Makefile or some other build system: like Scons (which are often easier to set up than Makefiles).
If you want to use #include <myheader.hpp> inside your cpp files you can use:
g++ *.cpp -I. -o out
I used to use a custom Makefile that compiled all the files in current directory, but I had to copy it in every directory I needed it, everytime.
So I created my own tool - Universal Compiler which made the process much easier when compile many files.
You can do that using a single command assuming all the needed .cpp and .h files are in the same folder.
g++ *.cpp *.h -Wall && ./a.out
It will compile and execute at the same time.
when using compiler in the command line, you should take of the following:
you need not compile a header file, since header file gets substituted in the script where include directive is used.
you will require to compile and link the implementation and the script file.
for example let cow.h be header file and cow.cpp be implementation file and cow.cc(c++ files can have extension .cpp, .cc, .cxx, .C, .CPP, .cp) be script file.
Since gcc compiler notation for c++ file is g++, we can compile and link the files using
$g++ -g -Wall cow.cpp cow.cc -o cow.out
options '-g' and '-Wall' are for debugging info and getting warning for errors. Here cow.out is the name of the executable binary file that we can execute to run the program. it is always good to name your executable file otherwise name will be automatically given which might be confusing at times.
you can also do the same by using makefiles, makefiles will detect, compile and link automatically the specified files.
There are great resources for compilation using command line
enter link description here
~/In_ProjectDirectory $ g++ coordin_main.cpp coordin_func.cpp coordin.h
~/In_ProjectDirectory $ ./a.out
... Worked!!
Using Linux Mint with Geany IDE
When I saved each file to the same directory, one file was not saved correctly within the directory; the coordin.h file. So, rechecked and it was saved there as coordin.h, and not incorrectly as -> coordin.h.gch. The little stuff.
Arg!!