gfortran, DLL, underscore - dll

I want to access some subroutines from a third party DLL. The functions use STDCALL as the calling convention.
Running dumpbin /export foo.dll gives me something like:
...
7 6 00004B40 Foo#16
...
I compile my code using:
gfortran test.f90 -o test.exe -Wl,foo.dll
I get an error: undefined reference to '_foo_' (note the underscores).
I have tried adding the -mrtd compilation flag, as well as other flags I googled, all to no avail.
How can I tell fortran to not add the underscores?
edit: A bit of clarification is in order.
I have an existing DLL to which I do not have the source to.
This DLL is written in Visual Basic, if it helps.
I want to call this DLL from fortran.
When I write in test.f90: Foo(1.0d0) I get an undefined reference to '_foo_' linkage error

Did you try -fno-underscoring ?
I found a post by Tobias Burnus (a gfortran developer) at http://www.rhinocerus.net/forum/lang-fortran/604847-fortran-dll-call-excel-2.html (near the end) -- he recommends the use of compiler directives instead of -mrtd.

You need to combine the use of ISO_C_BINDING with compiler attributes. You should really read the Mixed-Language Programming section of the gfortran manual. It gives good advice that can be used with other compilers as well. In particular, in your case you need the stdcall attribute:
interface VisBasSubs
subroutine foo (DoubleArg) bind (C, name="Foo")
!GCC$ ATTRIBUTES stdcall :: foo
use iso_c_binding, only: c_double
real (kind=c_double), intent (inout) :: DoubleArg
end subroutine foo
end interface VisBasSubs
Notice the line with stdcall, it's what should make it work.

Just wanted to expand on M.S.B's -fno-underscoring answer: You may run into issues if using f2c & g77. From the gfortran documentation:
With -funderscoring in effect, GNU
Fortran appends one underscore to
external names with no underscores.
This is done to ensure compatibility
with code produced by many UNIX
Fortran compilers.
Caution: The default behavior of GNU
Fortran is incompatible with f2c and
g77, please use the -ff2c option if
you want object files compiled with
GNU Fortran to be compatible with
object code created with these tools.
Use of -fno-underscoring is not
recommended unless you are
experimenting with issues such as
integration of GNU Fortran into
existing system environments
(vis-à-vis existing libraries, tools,
and so on).
You might need to recompile the DLL with something like -fno-underscoring to remove the underscores from the DLL.
I've run into portability issues related to underscore prefix/suffix by certain Fortran compilers: Some compilers _prefix or suffix_ by default, while others don't! My solution has been preprocessor directives:
#ifdef LC_UNSC
#define GET_DIP_MOMENT get_dip_moment_
#elif LC_NOUNSC
#define GET_DIP_MOMENT get_dip_moment
#endif
...
call GET_DIP_MOMENT()

A different approach is to use the ISO C Binding of Fortran 2003, which is supported by gfortran >= 4.3. This will automatically use the underscoring conventions of C (i.e., probably none), rather those of the Fortran compiler. It will also give you control over the case (capitalization) of the subroutine names, if the Windows linker cares about that. Fortran is case insensitive, and so you can call Fortran subroutines by any case -- probably the linker is converting to lower case.
Including the following "interface" in the declarations of the Fortran routine that calls "Foo" describes Foo to be a C subroutine (void function) with a single argument of double type -- Fortran input/output, or a pointer in C. If Foo has other properties, the interface needs to be changed. The "bind" clause specifies the case-sensitive name to provide to the linker. If you call Foo from several Fortran routines, then it is best to put the interface into a module and "use" it from each Fortran routine.
This is intended for C -- maybe it will work for Visual Basic. The ISO C Binding gives a lot of control, so if this doesn't work, maybe some variation will.
interface VisBasSubs
subroutine foo (DoubleArg) bind (C, name="Foo")
use iso_c_binding, only: c_double
real (kind=c_double), intent (inout) :: DoubleArg
end subroutine foo
end interface VisBasSubs

Related

How can I define an executable that has different compiler command-line arguments?

I have a C++ project and I want to test the compatibility of library headers with different compiler versions. I have a simple source file (that includes said headers) and I want to change the compiler argument to std=gnu++11 for this one target. How do I do that?
executable('old_compiler_test', ['octest.cxx']
# override ARGS here ??? how
)
Note that I have
add_global_arguments(
['-std=gnu++17',
....
rather than the dedicated option for this, in spite of the warning to prefer the special option, because the special option simply doesn't work. (Why is a question I've never tracked down)
update
To clarify: I'm not trying to make additional configurations in the same way that debug and release are configurations. I want a different compiler argument to be applied to a single target within the configuration.
From the Meson documentation, you can use the argument <languagename>_args to pass additional compiler arguments. In your case, since you use C++, it would give something like
executable('old_compiler_test', ['octest.cxx'],
cpp_args: ['std=gnu++11']
)
However the documentation also specify that there are no way to disable an argument added by add_global_argument(), so you will end up with both -std=gnu++17 and -std=gnu++11 passed to the compiler. I don't know how your compiler will behave, but I tried to pass both arguments to GCC 10.2 and it uses c++17 (not what you want).
Workaround
It seems that if you define the C++ version in the project() statement, Meson will removes it if an other version is specified in compiler arguments, giving the behaviour you expect.
Here is the sample I used:
meson.build
project('project-name', 'cpp',
default_options: ['cpp_std=c++17']
)
executable('old_compiler_test', ['octest.cxx'],
cpp_args: ['-std=gnu++11']
)
octest.cxx
#include <iostream>
int main() {
std::cout << __cplusplus << std::endl;
}
After compilation, running the executable will print 201103, which means that the compiler used c++11 as desired.

What is meaning of 'set(CMAKE_REQUIRED_LIBRARIES "m")' in CMake Tutorial?

I am learning CMake with CMake Tutorial and found something which is not clear for me:
include(CheckSymbolExists)
set(CMAKE_REQUIRED_LIBRARIES "m")
So what is the CheckSymbolExists? Is it a function or a lib?
What's meaning of the "m"? Does it mean a lib name or some flag?
I had tried to read through cmake documents, but I just don't understand.
Please somebody help me to understand these.
First, set(CMAKE_REQUIRED_LIBRARIES "m") includes the math library. You do the same on the command-line like this: gcc test.c -lm which includes the library libm.so/.dll
CheckSymbolExists is a CMake Module which provides more functionality. You can include it with include(CheckSymbolExists)
After this you can use the function check_symbol_exists(...) in CMake to check the availability of symbols in header files.
The exact example from the tutorial:
check_symbol_exists(log "math.h" HAVE_LOG) checks if the header file math.h has a symbol (can be a function, constant or whatever) which is called log. If there is one, the CMake Variable HAVE_LOG is set to 1, otherwise set to 0.
The document said, if my understanding is correct, this module will check if a symbol can be correctly linked when it saw a symbol that is not a enum, type or intrinsic.
So in that snippet, when the first runs of check_symbol_exists didn't define the two cache variable, it will check if it had missed an required lib, and retry.

How can I build a program using g++ with SCons, without depending on any external environmental variables?

I am trying to build a simple c++ hello world program using g++ with SCons. How can I specify that I want SCons to use g++ without any dependencies on external environment variables, such as PATH?
This is what I've tried:
env = Environment(CXX = 'C:/cygwin/bin/g++')
env.Program('helloworld.c++')
This is my result:
scons: warning: No version of Visual Studio compiler found - C/C++
compilers most likely not set correctly
File "C:\Python27\Scripts\scons.py", line 201, in <module>
C:/cygwin/bin/g++ /Fohelloworld.obj /c helloworld.c++ /TP /nologo
g++: error: /Fohelloworld.obj: No such file or directory
g++: error: /c: No such file or directory
g++: error: /TP: No such file or directory
g++: error: /nologo: No such file or directory
scons: *** [helloworld.obj] Error 1
scons: building terminated because of errors.
Turns out the answer was staring me straight in the face. My first problem was that the first part of this answer:
import os
env = Environment(ENV = {'PATH' : os.environ['PATH']})
utilizes the OS PATH, which I explicitly wanted to avoid. My second problem was that I completely overlooked the answer below, which was the precise answer to my question:
The way to guarantee that the build is repeatable is to explicitly
initialize the PATH
path= ['/bin', '/usr/bin', '/path/to/other/compiler/bin']
env = Environment(ENV = {'PATH' : path})
The reason I didn't realize this was the solution is because I simply misunderstood that env['ENV']['PATH'] and os.environ['PATH'] are completely separate and distinct. Whereas os.environ['PATH'] is obviously the external OS PATH, env['ENV']['PATH'] seems to be SCons' internal equivalent. You can set is to be whatever you please.
In the end, the precise solution I chose, and the one most readable to me was:
PATH = {'PATH' : ['C:/cygwin/bin']}
env = Environment(ENV = PATH)
env['ENV'] = PATH
env['CXX'] = 'g++'
env.Program('helloworld.c++')
A slightly cleaner way
env = Environment(tools=['g++','gnulink'])
env['ENV']['PATH'] = ['C:/cygwin/bin']
env['CXX'] = 'g++'
env.Program('helloworld.c++')
Another way:
env = Environment(tools=['g++','gnulink'])
env.PrependENVPath('PATH','C:/cygwin/bin')
env.Program('helloworld.c++')
Try this:
env = Environment(tools=['ar', 'cc', 'clang', 'clangxx', 'gcc', 'g++', 'gnulink', 'link'], ENV=os.environ, toolpath=['custom_path']).
The command above will:
Create a variable env of type Environment.
Tells scons to set up requires tools.
Find these tools in system variable.
Else find in custom path(you can omit the last parameter: toolpath=['custom_path'] if you don't need it).
Where:
ar: Sets construction variables for the ar library archiver.
Sets: $AR, $ARCOM, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX, $RANLIB, $RANLIBCOM, $RANLIBFLAGS.
cc: Sets construction variables for generic POSIX C compilers.
Sets: $CC, $CCCOM, $CCFLAGS, $CFILESUFFIX, $CFLAGS, $CPPDEFPREFIX, $CPPDEFSUFFIX,$FRAMEWORKPATH, $FRAMEWORKS, $INCPREFIX, $INCSUFFIX, $SHCC, $SHCCCOM, $SHCCFLAGS,$SHCFLAGS, $SHOBJSUFFIX.
clang: Set construction variables for the Clang C compiler.
Sets: $CC, $CCVERSION, $SHCCFLAGS.
clangxx: Set construction variables for the Clang C++ compiler.
Sets: $CXX, $CXXVERSION, $SHCXXFLAGS, $SHOBJSUFFIX,$STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME.
g++: Set construction variables for the gXX C++ compiler.
Sets: $CXX, $CXXVERSION, $SHCXXFLAGS, $SHOBJSUFFIX.
gcc: Set construction variables for the gcc C compiler.
Sets: $CC, $CCVERSION, $SHCCFLAGS.
gnulink: Set construction variables for GNU linker/loader
Sets: $LDMODULEVERSIONFLAGS, $RPATHPREFIX, $RPATHSUFFIX, $SHLIBVERSIONFLAGS,$SHLINKFLAGS, $_LDMODULESONAME, $_SHLIBSONAME.
link: Sets construction variables for generic POSIX linkers. This is a "smart" linker tool which selects a compiler tocomplete the linking based on the types of source files.
Sets: $LDMODULE, $LDMODULECOM, $LDMODULEFLAGS, $LDMODULENOVERSIONSYMLINKS,$LDMODULEPREFIX, $LDMODULESUFFIX, $LDMODULEVERSION, $LDMODULEVERSIONFLAGS,$LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK,$LINKCOM, $LINKFLAGS, $SHLIBSUFFIX, $SHLINK, $SHLINKCOM, $SHLINKFLAGS,$__LDMODULEVERSIONFLAGS, $__SHLIBVERSIONFLAGS.Uses: $LDMODULECOMSTR, $LINKCOMSTR, $SHLINKCOMSTR
Or you can use default config tools for your system by:
env = Environment(tools=['default'], ENV=os.environ)
To quote from scons man 4.1.0
default
Sets construction variables for a default list of Tool modules. Use
default in the tools list to retain the original defaults, since the
tools parameter is treated as a literal statement of the
tools to be made available in that construction environment, not
an addition.
The list of tools selected by default is not static, but
is dependent both on the platform and on the software installed on the
platform. Some tools will not initialize if an underlying command is
not found, and some tools are selected from a list of choices on
a first-found basis. The finished tool list can be examined
by inspecting the TOOLS construction variable in the construction
environment.
On all platforms, all tools from the following list are
selected whose respective conditions are met: filesystem,wix, lex,
yacc, rpcgen, swig, jar, javac, javah, rmic, dvipdf, dvips, gs, tex,
latex, pdflatex, pdftex, tar, zip, textfile.
On Linux systems, the
default tools list selects (first-found): a C compiler from gcc,
intelc, icc, cc; a C++ compilerfrom g++, intelc, icc, cxx; an
assembler from gas, nasm, masm; a linker from gnulink, ilink; a
Fortran compilerfrom gfortran, g77, ifort, ifl, f95, f90, f77; and a
static archiver 'ar'. It also selects all found from the list m4,
rpm.
On Windows systems, the default tools list selects
(first-found): a C compiler from msvc, mingw, gcc, intelc,icl,
icc, cc, bcc32; a C++ compiler from msvc, intelc, icc, g++, cxx,
bcc32; an assembler from masm, nasm, gas,386asm; a linker from mslink,
gnulink, ilink, linkloc, ilink32; a Fortran compiler from gfortran,
g77, ifl, cvf, f95,f90, fortran; and a static archiver from mslib, ar,
tlib; It also selects all found from the list msvs, midl.
On MacOS
systems, the default tools list selects (first-found): a C compiler
from gcc, cc; a C++ compiler from g++, cxx; an assembler 'as'; a
linker from applelink, gnulink; a Fortran compiler from gfortran, f95,
f90, g77; anda static archiver ar. It also selects all found from the
list m4, rpm.
Default lists for other platforms can be found by
examining the scons source code (see SCons/Tool/init.py).

Fortran: Is there a way to conditionally use modules?

Assume I have two Fortran modules called modA and modB. Is there a way to use one or the other in a program based on a conditional statement? Does this require some type of preprocessing? For example, I want to be able to do something like the following code:
if (condition)
use modA
else
use modB
end
I am using the GNU Fortran compiler.
Yes, you must do some kind of preprocessing. The most common is the C preprocessor included in GNU Fortran.
#if (condition)
use modA
#else
use modB
#endif
The preprocessor does not understand your Fortran code, it is only a text for it. It has it's own set of directives and it's own set of variables. Only the preprocessor variables can be used in the condition, not your Fortran variables.
Another common directive is #ifdef which is a variant of #if defined. See the manual for more https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html (gfortran runs the preprocessor in the traditional mode).
To enable the preprocessor use the -cpp flag or in Unix you can use capital F in the file suffix.

Determining symbol addresses using binutils/readelf

I am working on a project where our verification test scripts need to locate symbol addresses within the build of software being tested. This might be used for setting breakpoints or reading static data from memory. What I am after is to create a map file containing symbol names, base address in memory, and size. Our build outputs an ELF file which has the information I want. I've been trying to use the readelf, nm, and objdump tools to try and to gain the symbol addresses I need.
I originally tried readelf -s file.elf and that seemed to access some symbols, particularly those which were written in assembler. However, many of the symbols that I wanted were not in there - specifically those that originated within our Ada code.
I used readelf --debug-dump file.elf to dump all debug information. From that I do see all symbols, including those that were in the Ada code. However, the format seems to be in the DWARF format. Does anyone know why these symbols would not be output by readelf when I ask it to list the symbolic information? Perhaps there is simply an option I am missing.
Now I could go to the trouble of writing a custom DWARF parser to get the information but if I can get it using one of the Binutils (nm, readelf, objdump) then I'd really like prefer a standard solution.
DWARF is the debug information and tries to reflect the relation of the original source code. Taking following code as an example
static int one() {
// something
return 1;
}
int main(int ac, char **av) {
return one();
}
After you compile it using gcc -O3 -g, the static function one will be inlined into main. So when you use readelf -s, you will never see the symbol one. However, when you use readelf --debug-dump, you can see one is a function which is inlined.
So, in this example, compiler does not prohibit you use optimization with -g, so you can still debug the executable. In that example, even the function is optimized and inlined, gdb still can use DWARF information to know the function and source/line from current code block inside inlined function.
Above is just a case of compiler optimization. There might be plenty of reasons that could lead to mismatch symbols address between readelf -s and DWARF.