I installed gcc and gfortran on AIX, and they work fine. Among other things I use them with some libraries which are accessed by header files (.h in C). The very same libraries can be used with modules (.mod in fortran), but as you know their use is optional: if I comment out the
use mylib
implicit none
from my fortran source code, everything works fine. Problem is, I don't want to comment out the implicit none, so I have to keep the use mylib too, otherwise I'll get a bunch of
Error: Symbol 'foo' at (1) has no IMPLICIT type
errors. And, as you know, the .mod files are compiler dependent, so I cannot use the ones I have, otherwise gfortran will spit:
Fatal Error: File 'mylib.mod' opened at (1) is not a GFORTRAN module file
Theoretically I could recompile all the libraries with gfortran, but most likely it will fail for various reasons (and if it doesn't it will still be a daunting task).
So I am wondering if there is a way to precompile the .h header in a .mod module, providing just the interface information which is all that is needed. Unfortunately, I wasn't able to find any information about this.
C header files will not produce Fortran module files. Fortran module files are compiler-dependent but are normally produced when you compile Fortran files containing modules. They record information about a source-code module, such as the procedures that it contains and their calling conventions, for use by the compiler when it encounters calls to those procedures. This is the method by which the compiler makes calls to module routines automatically explicit. Typically you have to compile the Fortran-source code file containing the module (here module "mylib") before you compile a file that has a main program or procedure that uses it. Why do you assume that compiling the libraries with gfortran will most likely fail, or will be daunting? I suggest giving it a try. You can't compile a C .h file into a module. If the author of a Fortran library wanted to they could provide a file with Fortran interfaces which described the procedures and that could be compiled into a module. But that technique is error prone, because it means that there are two items that have to be kept in agreement.
If the libraries are in C and are being called from Fortran through the ISO C Binding, then the best technique is to write a file with interfaces. Was such a Fortran file provided? Were did the incorrect module files come from? When you compile that file with gfortran you will get the .mod file. While the duplication between the actual C source code and the Fortran interface declarations means two items have to be maintained, in this case it is necessary since the original source code is in C and the Fortran interface statements describe the C routines to the Fortran compiler in Fortran.
You could declare the functions/subroutines you use from the module as external in a custom-made file mylib.fh, for example:
#mylib.fh
external my_function
In you fortran code, you would then use:
implicit none
include 'mylib.fh'
Related
How to directly run a c++ file present in read-only storage like CD-drive without making executable files using g++? There must be some arguments for that to work.
The process of a C/C++ program when you make one till you run it:
You write the program's source code.
The compiler comes in here and compiles the source code to object files.
Note: Remember that the program cannot be executed at this stage. It's only an object file. You'd know this if you have worked on bigger size programs, but if you haven't here is how it works. Remember using those header files in your programs? These header files just tell the compiler that there are some things that are not defined in your program. They are somewhere else. So your compile compiles the program to the object file leaving out things that have a prototype (which is in the header files).
This is a very important point. Here a program called 'linker' comes into play. What linker does is to take all the object files created by compiler and combines them into one. Say for example your compiler created a single object file. Now, you're using math library or anything from standard library. The compiler-linker package (often called only compiler) comes with object files for these standard library definitions. So, linker takes your object file and combines it with other object files from the package and then converts it to an executable file. This is the file that you can run. Nothing else is runnable directly.
To run source code the process is explained already, we have to use the g++. Now
What I understand from your question is that you want to know if a program can be run once it's compiled and linked properly (hence an executable has been generated). Answer to that would be yes.
Alternatively, may sound strange, there is an interpreter I know called Cling that can be of use to bypass the compilation of C++ program.
After all C++ is generally seen as a compiled language. However, any programming language can be implemented as a compiler or as an interpreter and Cling happens to be an interactive C++ interpreter based on LLVM and Clang.
Take a thorough look at this
I know very little about DLL's and LIB's other than that they contain vital code required for a program to run properly - libraries. But why do compilers generate them at all? Wouldn't it be easier to just include all the code in a single executable? And what's the difference between DLL's and LIB's?
There are static libraries (LIB) and dynamic libraries (DLL) - but note that .LIB files can be either static libraries (containing object files) or import libraries (containing symbols to allow the linker to link to a DLL).
Libraries are used because you may have code that you want to use in many programs. For example if you write a function that counts the number of characters in a string, that function will be useful in lots of programs. Once you get that function working correctly you don't want to have to recompile the code every time you use it, so you put the executable code for that function in a library, and the linker can extract and insert the compiled code into your program. Static libraries are sometimes called 'archives' for this reason.
Dynamic libraries take this one step further. It seems wasteful to have multiple copies of the library functions taking up space in each of the programs. Why can't they all share one copy of the function? This is what dynamic libraries are for. Rather than building the library code into your program when it is compiled, it can be run by mapping it into your program as it is loaded into memory. Multiple programs running at the same time that use the same functions can all share one copy, saving memory. In fact, you can load dynamic libraries only as needed, depending on the path through your code. No point in having the printer routines taking up memory if you aren't doing any printing. On the other hand, this means you have to have a copy of the dynamic library installed on every machine your program runs on. This creates its own set of problems.
As an example, almost every program written in 'C' will need functions from a library called the 'C runtime library, though few programs will need all of the functions. The C runtime comes in both static and dynamic versions, so you can determine which version your program uses depending on particular needs.
Another aspect is security (obfuscation). Once a piece of code is extracted from the main application and put in a "separated" Dynamic-Link Library, it is easier to attack, analyse (reverse-engineer) the code, since it has been isolated. When the same piece of code is kept in a LIB Library, it is part of the compiled (linked) target application, and this thus harder to isolate (differentiate) that piece of code from the rest of the target binaries.
One important reason for creating a DLL/LIB rather than just compiling the code into an executable is reuse and relocation. The average Java or .NET application (for example) will most likely use several 3rd party (or framework) libraries. It is much easier and faster to just compile against a pre-built library, rather than having to compile all of the 3rd party code into your application. Compiling your code into libraries also encourages good design practices, e.g. designing your classes to be used in different types of applications.
A DLL is a library of functions that are shared among other executable programs. Just look in your windows/system32 directory and you will find dozens of them. When your program creates a DLL it also normally creates a lib file so that the application *.exe program can resolve symbols that are declared in the DLL.
A .lib is a library of functions that are statically linked to a program -- they are NOT shared by other programs. Each program that links with a *.lib file has all the code in that file. If you have two programs A.exe and B.exe that link with C.lib then each A and B will both contain the code in C.lib.
How you create DLLs and libs depend on the compiler you use. Each compiler does it differently.
One other difference lies in the performance.
As the DLL is loaded at runtime by the .exe(s), the .exe(s) and the DLL work with shared memory concept and hence the performance is low relatively to static linking.
On the other hand, a .lib is code that is linked statically at compile time into every process that requests. Hence the .exe(s) will have single memory, thus increasing the performance of the process.
I'm porting an old C++ project to run on RHEL 6.7 with gcc 4.4.7. The code was originally made to run on an SGI machine.
I have a library .a which is presumed to have been compiled on the old machine (and thus there's no hope of running it in the new one) however, along with this .a file I also have the headers and source files. I am assuming that these are the ones that are used to make the .a file. The Makefile that was used is now long gone, I just have the source code.
My question is, is there a way to "reverse engineer" the library? I would like to know what functions the .a library contains so I can make it on my machine.
I will add that I am new to static and shared libraries so I'm not entirely sure what the .a file contains or how it is any different from including the headers.
Update:
I have looked into the included code and realized that the C files only work to interface with functions defined using Fortran95. I think that now I'm supposed to build the Fortran95 codebase and somehow interface that with the C code. Once I do that I will have a library that should (hopefully) compile in my native system. How can I do this?
I am giving Gwan a whirl.
Having made it through example code, I started a small project with more than one source file. I now have two problems:
I got a linking error at server startup:
Linking main.cpp: undefined symbol: _ZN7GwanUrl9concatAllEv
(the main file #includes the two other files; all the files are in the csp directory)
As an alternative to having all the files in the /csp directory, I would like to make a library outside of the /csp directory while still using some of the gwan functions. sadly, a tonne of errors follow -- WHEN I GCC from commandline not via G-WAN Startup.
In file included from /home/ec2-user/gwan/include/gwan.h:22,
from Xbufstream.h:10,
from Xbufstream.cpp:10:
/usr/include/time.h:199: error: ‘size_t’ does not name a type
.....
Anyone knows what the gwan g++ argument string looks like?
(odd the 1. and 1. its 1. and 2. in the editor)
First, this is not a linker issue: you have "undefined symbol" rather than "unresolved symbol" as an error.
This is simply an #include issue.
define the main() function in your script.cpp file.
there's a G-WAN folder dedicated to user-defined include files called /gwan/include but you can as well use /csp/my_include.hpp... if you are using the right syntax:
For example, having #include "toto.hpp" in /csp/hello.cpp lets me reach C++ functions defined and implemented in the gwan/include/toto.hpp file (or defined in toto.hpp and implemented in a pre-compiled library linked to your script with #pragma link).
If you rather use #include <toto.hpp> then the SYSTEM INCLUDE PATH will be searched instead (and this will work providing that your library was correctly installed).
If you want to use #include "toto.hpp" for a custom folder that was not setup in the system, you can use G-WAN's #pragma include "../my_folder" directive to specify its PATH or you can explicitely specify it in each include: #include "../my_folder/toto.hpp".
Nothing fancy there, only C/C++ dependancy rules apply (and G-WAN really helps by providing alternate ways that do not involve system settings).
For libraries (see the G-WAN examples for SQLite, Cairo, mySQL, cURL, etc.) you can either use pre-installed libraries that exported their location in SYSTEM variables... or put your library in the /gwan/libraries folder and their include file in the /gwan/include folder.
When writing your own libraries, remember that they need to be pre-compiled. This means that you obviously cannot use G-WAN symbols since your compiler may #include "gwan.h" (to have the definitions) but your linker will not know from where G-WAN symbols can be found. The way around is to always use the G-WAN API from the G-WAN scripts. Your custom libraries must either be general-purpose or buffer any payload intended to be used by G-WAN. No-double copy is needed since G-WAN provides the set_reply() call to let G-WAN use persistent replies built without the reply xbuffer provided by G-WAN servlets.
Now, a last word about linking (which was not the cause of your trouble but could participate to the confusion). If you mix C and C++, use extern C {} to wrap your C++ prototypes called from C (otherwise you will really have "unresolved symbols").
With all this information, you should be ready to face every possible situation.
the issue of referencing gwan.h symbols inside #include files can also be solved by moving all code into the header file, whether its .h or .hpp
its ungraceful but a fix nevertheless. and good enough for the simple extension i wanted.
looking into the /libraries/sqlite3/sqlite.h helped.
#gil, thanks for your time.
UPDATE After some digging I found this to be a part of some workaround that passed a file handle from C++ to Fortran using a stub for OPENPIPE. OPENPIPE simply returns an externally declared file handle, doing absolutely nothing with a pipe. OPENHOLDFILENAME actually creates a file, but I'm still confused about what DFWIN has to do with this. Was it required to provide a function declaration for OPENPIPE? If so, they why was it also declared as EXTERNAL in the Fortran code?
I was given the task of compiling legacy Fortran on the GCC toolchain. I've already successfully compiled a few of the source files, but have hit a snag regarding the DFWIN module which links up to some Win32 API functions. It apparently uses some Win32 pipe functions, and I need to replace this with a modern equivalent that works with gfortran (the old compiler was Compaq Visual Fortran).
First, I see the DFWIN module included, as well as some external functions:
USE DFWIN
EXTERNAL OPENPIPE
EXTERNAL OPENHOLDFILENAME
Here is an example of how OPENPIPE is used:
OPEN(UNIT=INN,FILE=
1 '\\.\pipe\input.txt',
1 FORM='FORMATTED',STATUS='old',readonly,
1 USEROPEN=OPENPIPE)
What module can I use to replace these calls on modern Windows/Linux systems using gcc/gfortran?
EDIT: Our priority is to get this running on Windows, but in the future we want to deploy on Linux as well.