Hi I am currently installing a software called super LU and in the README file there is the following instruction for modifying a makefile depending on system set-up.
C preprocessor definition CDEFS.
In the header file SRC/Cnames.h, we use macros to determine how
C routines should be named so that they are callable by Fortran.
(Some vendor-supplied BLAS libraries do not have C interfaces. So the
re-naming is needed in order for the SuperLU BLAS calls (in C) to
interface with the Fortran-style BLAS.)
The possible options for CDEFS are:
o -DAdd_: Fortran expects a C routine to have an underscore
postfixed to the name;
o -DNoChange: Fortran expects a C routine name to be identical to
that compiled by C;
o -DUpCase: Fortran expects a C routine name to be all uppercase.
A Makefile is provided in each subdirectory. The installation can be done
completely automatically by simply typing "make" at the top level.
I am not really sure what this instruction means. Which of these three options should I choose?
Just try building the software running make at the top level.
If there are linking problems because of missing BLAS functions
start experimenting with underscore.
So start with NoChange, then try Add_.
Related
I am trying to build a Fortran program, but I get errors about an undefined reference or an unresolved external symbol. I've seen another question about these errors, but the answers there are mostly specific to C++.
What are common causes of these errors when writing in Fortran, and how do I fix/prevent them?
This is a canonical question for a whole class of errors when building Fortran programs. If you've been referred here or had your question closed as a duplicate of this one, you may need to read one or more of several answers. Start with this answer which acts as a table of contents for solutions provided.
A link-time error like these messages can be for many of the same reasons as for more general uses of the linker, rather than just having compiled a Fortran program. Some of these are covered in the linked question about C++ linking and in another answer here: failing to specify the library, or providing them in the wrong order.
However, there are common mistakes in writing a Fortran program that can lead to link errors.
Unsupported intrinsics
If a subroutine reference is intended to refer to an intrinsic subroutine then this can lead to a link-time error if that subroutine intrinsic isn't offered by the compiler: it is taken to be an external subroutine.
implicit none
call unsupported_intrinsic
end
With unsupported_intrinsic not provided by the compiler we may see a linking error message like
undefined reference to `unsupported_intrinsic_'
If we are using a non-standard, or not commonly implemented, intrinsic we can help our compiler report this in a couple of ways:
implicit none
intrinsic :: my_intrinsic
call my_intrinsic
end program
If my_intrinsic isn't a supported intrinsic, then the compiler will complain with a helpful message:
Error: ‘my_intrinsic’ declared INTRINSIC at (1) does not exist
We don't have this problem with intrinsic functions because we are using implicit none:
implicit none
print *, my_intrinsic()
end
Error: Function ‘my_intrinsic’ at (1) has no IMPLICIT type
With some compilers we can use the Fortran 2018 implicit statement to do the same for subroutines
implicit none (external)
call my_intrinsic
end
Error: Procedure ‘my_intrinsic’ called at (1) is not explicitly declared
Note that it may be necessary to specify a compiler option when compiling to request the compiler support non-standard intrinsics (such as gfortran's -fdec-math). Equally, if you are requesting conformance to a particular language revision but using an intrinsic introduced in a later revision it may be necessary to change the conformance request. For example, compiling
intrinsic move_alloc
end
with gfortran and -std=f95:
intrinsic move_alloc
1
Error: The intrinsic ‘move_alloc’ declared INTRINSIC at (1) is not available in the current standard settings but new in Fortran 2003. Use an appropriate ‘-std=*’ option or enable ‘-fall-intrinsics’ in order to use it.
External procedure instead of module procedure
Just as we can try to use a module procedure in a program, but forget to give the object defining it to the linker, we can accidentally tell the compiler to use an external procedure (with a different link symbol name) instead of the module procedure:
module mod
implicit none
contains
integer function sub()
sub = 1
end function
end module
use mod, only :
implicit none
integer :: sub
print *, sub()
end
Or we could forget to use the module at all. Equally, we often see this when mistakenly referring to external procedures instead of sibling module procedures.
Using implicit none (external) can help us when we forget to use a module but this won't capture the case here where we explicitly declare the function to be an external one. We have to be careful, but if we see a link error like
undefined reference to `sub_'
then we should think we've referred to an external procedure sub instead of a module procedure: there's the absence of any name mangling for "module namespaces". That's a strong hint where we should be looking.
Mis-specified binding label
If we are interoperating with C then we can specify the link names of symbols incorrectly quite easily. It's so easy when not using the standard interoperability facility that I won't bother pointing this out. If you see link errors relating to what should be C functions, check carefully.
If using the standard facility there are still ways to trip up. Case sensitivity is one way: link symbol names are case sensitive, but your Fortran compiler has to be told the case if it's not all lower:
interface
function F() bind(c)
use, intrinsic :: iso_c_binding, only : c_int
integer(c_int) :: f
end function f
end interface
print *, F()
end
tells the Fortran compiler to ask the linker about a symbol f, even though we've called it F here. If the symbol really is called F, we need to say that explicitly:
interface
function F() bind(c, name='F')
use, intrinsic :: iso_c_binding, only : c_int
integer(c_int) :: f
end function f
end interface
print *, F()
end
If you see link errors which differ by case, check your binding labels.
The same holds for data objects with binding labels, and also make sure that any data object with linkage association has matching name in any C definition and link object.
Equally, forgetting to specify C interoperability with bind(c) means the linker may look for a mangled name with a trailing underscore or two (depending on compiler and its options). If you're trying to link against a C function cfunc but the linker complains about cfunc_, check you've said bind(c).
Not providing a main program
A compiler will often assume, unless told otherwise, that it's compiling a main program in order to generate (with the linker) an executable. If we aren't compiling a main program that's not what we want. That is, if we're compiling a module or external subprogram, for later use:
module mod
implicit none
contains
integer function f()
f = 1
end function f
end module
subroutine s()
end subroutine s
we may get a message like
undefined reference to `main'
This means that we need to tell the compiler that we aren't providing a Fortran main program. This will often be with the -c flag, but there will be a different option if trying to build a library object. The compiler documentation will give the appropriate options in this case.
There are many possible ways you can see an error like this. You may see it when trying to build your program (link error) or when running it (load error). Unfortunately, there's rarely a simple way to see which cause of your error you have.
This answer provides a summary of and links to the other answers to help you navigate. You may need to read all answers to solve your problem.
The most common cause of getting a link error like this is that you haven't correctly specified external dependencies or do not put all parts of your code together correctly.
When trying to run your program you may have a missing or incompatible runtime library.
If building fails and you have specified external dependencies, you may have a programming error which means that the compiler is looking for the wrong thing.
Not linking the library (properly)
The most common reason for the undefined reference/unresolved external symbol error is the failure to link the library that provides the symbol (most often a function or subroutine).
For example, when a subroutine from the BLAS library, like DGEMM is used, the library that provides this subroutine must be used in the linking step.
In the most simple use cases, the linking is combined with compilation:
gfortran my_source.f90 -lblas
The -lblas tells the linker (here invoked by the compiler) to link the libblas library. It can be a dynamic library (.so, .dll) or a static library (.a, .lib).
In many cases, it will be necessary to provide the library object defining the subroutine after the object requesting it. So, the linking above may succeed where switching the command line options (gfortran -lblas my_source.f90) may fail.
Note that the name of the library can be different as there are multiple implementations of BLAS (MKL, OpenBLAS, GotoBLAS,...).
But it will always be shortened from lib... to l... as in liopenblas.so and -lopenblas.
If the library is in a location where the linker does not see it, you can use the -L flag to explicitly add the directory for the linker to consider, e.g.:
gfortran -L/usr/local/lib -lopenblas
You can also try to add the path into some environment variable the linker searches, such as LIBRARY_PATH, e.g.:
export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib
When linking and compilation are separated, the library is linked in the linking step:
gfortran -c my_source.f90 -o my_source.o
gfortran my_source.o -lblas
Not providing the module object file when linking
We have a module in a separate file module.f90 and the main program program.f90.
If we do
gfortran -c module.f90
gfortran program.f90 -o program
we receive an undefined reference error for the procedures contained in the module.
If we want to keep separate compilation steps, we need to link the compiled module object file
gfortran -c module.f90
gfortran module.o program.f90 -o program
or, when separating the linking step completely
gfortran -c module.f90
gfortran -c program.f90
gfortran module.o program.o -o program
Problems with the compiler's own libraries
Most Fortran compilers need to link your code against their own libraries. This should happen automatically without you needing to intervene, but this can fail for a number of reasons.
If you are compiling with gfortran, this problem will manifest as undefined references to symbols in libgfortran, which are all named _gfortran_.... These error messages will look like
undefined reference to '_gfortran_...'
The solution to this problem depends on its cause:
The compiler library is not installed
The compiler library should have been installed automatically when you installed the compiler. If the compiler did not install correctly, this may not have happened.
This can be solved by correctly installing the library, by correctly installing the compiler. It may be worth uninstalling the incorrectly installed compiler to avoid conflicts.
N.B. proceed with caution when uninstalling a compiler: if you uninstall the system compiler it may uninstall other necessary programs, and may render other programs unusable.
The compiler cannot find the compiler library
If the compiler library is installed in a non-standard location, the compiler may be unable to find it. You can tell the compiler where the library is using LD_LIBRARY_PATH, e.g. as
export LD_LIBRARY_PATH="/path/to/library:$LD_LIBRARY_PATH"
If you can't find the compiler library yourself, you may need to install a new copy.
The compiler and the compiler library are incompatible
If you have multiple versions of the compiler installed, you probably also have multiple versions of the compiler library installed. These may not be compatible, and the compiler might find the wrong library version.
This can be solved by pointing the compiler to the correct library version, e.g. by using LD_LIBRARY_PATH as above.
The Fortran compiler is not used for linking
If you are linking invoking the linker directly, or indirectly through a C (or other) compiler, then you may need to tell this compiler/linker to include the Fortran compiler's runtime library. For example, if using GCC's C frontend:
gcc -o program fortran_object.o c_object.o -lgfortran
I was told to post compiling questions on stackoverflow so this is the same question I've posted to Ubuntu Ask!:
I'm trying to compile a program that came with a Makefile. The makefile uses f77 and it seems that the programs call several f95 intrinsics. When I try to compile I get:
plotkit.a(userid.o): In function userid_':
fort77-5163-1.c:(.text+0x13e): undefined reference togetgid_' fort77-5163-1.c:(.text+0x234): undefined reference to `getuid_' collect2: error: ld returned 1 exit status
I also get the same error with fdate on another program in this distribution. I've tried to change the makefile to use different compilers such as gfortran) and they all cause MORE errors.
My question is how do I get getgid, getuid, and fdate to work with a f77 program? I'm additionally confused because there are getgid and getuid man pages but no installation on ubuntu?
I have a 64 bit 14.04 LTS installation.
Thanks for any ideas.
By default, gfortran (and other Fortran compilers) mangle procedure names by adding an underscore. When you reference getgid in source, the compiler changes that to getgid_. If the function getgid isn't defined in Fortran source, e.g. in C, then this will cause link errors such as the one you are encountering.
The functions getgid, getuid, etc are not Fortran functions, they are standard C library functions. If the code you are using is from somewhere else, look and see if the provided Makefiles have options listed to disable default underscoring by Fortran. For gfortran, this option is -fno-underscoring. Append this to the compiler flags used for the Fortran compiler in the makefile. For other Fortran compilers, consult their documentation for similar options.
If you aren't restricted to F77 and can make use of modern Fortran features, the other option is to fix this by providing interoperable interfaces for C library functions. e.g.
interface
function getgid() bind(C,name='getgid')
use iso_c_binding
implicit none
integer(c_int32_t) :: getgid
end function getgid
end interface
This will define an explicit interface for the C library function getgid so that you can call it from a modern Fortran implementation. You would define interfaces like this for each of the C library functions you need to call.
* As an aside, while the above interface works and is portable from a modern Fortran perspective, it isn't 100% portable from a C library perspective. The GNU implementation of getgid returns the type gid_t which though a long chain of typedefs is finally related to a true type in the files /usr/include/bits/types.h and /usr/include/bits/typesizes.h as an unsigned 32 bit integer. Fortran doesn't have unsigned types so while the storage sizes will match, if these functions ever return values above around 2 billion, they will be misinterpreted in Fortran as negative values. Also, since the storage type of gid_t is defined in the "bits" C header tree, they are potentially non-portable (not sure if the storage size is specified in POSIX or some other standard or implementation dependent).
It is said that Pharo's VM (CogVM) is developed, tested, profiled and etc in Smalltalk, but then the Smalltalk code is transcompiled to C, which is then compiled along side with some OS abstraction C code using the default system C compiler.
Well, I'd like to do a similar thing, I wan't to develop, test and profile code using Pharo, but then compile it to C. How can I do it? How the compilation to C works? Does Pharo comes with a Smalltalk to C transcompiler? How can I invoke it? Does it compile the full Smalltalk, or I have to use some kind of a Smalltalk subset? Is there any good documentation about it?
The Pharo VM is hosted on github.
Follow the steps to build it and you'll get a Smalltalk image called "generator.image" which you can run (it's a regular image). Inside of that image you'll find the VMMaker package which is responsible for generating the C code from the special Smalltalk dialect used for this (which is called Slang; it's a subset of Smalltalk). Look at the code in the generator image to get a feel for what it does. There's also some information contained in the workspaces that are open when you first open the image.
As soon as you have the C sources it's basically straight forward C compilation (which we do with Cmake + gcc / clang).
As for documentation: you should probably read the Blue Book.
clarifiation
As #Leandro Caniglia points out in the comment, the purpose of Slang is to generate C source code for the VM. It has been designed to ease translation to C. That does not mean that:
arbitrary Smalltalk code can be translated to C using the generating mechanism
arbitrary Smalltalk code can be rewritten in Slang (at least not "easily")
I don't know if this is the right place for things like this, but I am curious about a few aspects of the GCC front-end/back-end architecture:
I know I can compile .o files from C code and link them to C++ code, and I think I can do it the other way round, too. Does this work because the two languages are similar, or because the GCC back-end is really language-independent? Would this work with ADA code too? (I don't even know if that makes sense, since I don't know ADA or if it even has "functions", but the question is understood. If it makes no sense, think "Pascal" or even "my own custom language front-end")
Where would garbage-collection be implemented? For example, a Java front-end. The way I understand, if compiling to a JVM back-end, the "platform" will take care of the GC, and so the front-end needs not do anything about it, but if compiling to native code, would the front-end send garbage-collecting GENERIC code to the back-end, or does it turn on some flag telling the back-end to produce garbage-collecting code? The first makes more sense to me, but that would mean the front-end produces different output based on the target, which seems to miss the point of the GCC's front-end/back-end architecture.
Where would language-specific libraries go? For instance, the standard Java classes or standard C headers. If they are linked in at the end, then could a C program theoretically call functions from the Java library or something like that, since it is just another linked library?
Yes, the backend is at least reasonably language independent. Yes, it works with Ada.
GCJ generates native code which uses a runtime library. The garbage collector is part of the runtime library.
GCJ implements the CNI, which allows you to write code in C++ that can be used as native methods by Java code -- but being able to do this is a consequence of them having designed it in, not just an accidental byproduct of using the same back-end.
It is possible because calling convention is compatible, but name mangling is different (no mangling in C). To call C function from C++ you should declare it with extern "C". And to call C++ function from C you should declare it with mangled name (and may be with additional or different type args). The calling Fortran code is possible in some cases too, but argument passing convention is different (pass by ref in Fortran).
There were actually a converters from C++ to C (cfront) and from fortran to c (f2c) and some solutions from them are still used.
garbage-collection is implemented in run-time library, e.g. boehm. Backend should generate objects compatible with selected GC library.
Compiler driver (g++, gfortran, ..) will add language-specific libraries to linking step.
I'm making an R package on data flows in networks. For speed, some of the code is written in C++, and with my own implementation of graph algorithms. I'd like to re-write my code to use the Boost Graph Library.
What would I need to put in the Makevars file to set the compiler/linker option to find boost? Sorry, I'm not very good with Make.
I'm working in a Linux environment
Yes I looked at RBGL, but did not find a makefile in that package
If it matters, I'm using Rcpp to interface the R and C++ code
It's not that hard. By default, every Rcpp package has a default src/Makevars which contains
## Use the R_HOME indirection to support installations of multiple R version
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
where the library for Rcpp itself is found dynamically by asking R. You just expand this and add
-lboost_graph
(and/or maybe the parallel or mt variants). If you they are installed in an unusual place, also add -L... flags. Dito for PKG_CFLAGS for header locations.
That's about it. See the Writing R Extensions manual about more details on building R packages.