I'm trying to get BLAS working with in a FORTRAN 77 program, but so far I've been unsuccesful and I can't figure out how to get going with this. For reference I'm doing this under Ubuntu 12.10.
This is the code of the program I'm trying to compile:
program blastest
implicit none
include 'cblas_f77.h'
end
The file cblas_f77.h resides in /usr/include, and there are both libblas.a and libblas.so (and a bunch of other BLAS related files) in /usr/lib.
How do you configure this to work properly?
So far, I've tried the following:
Note: adding -lblas to either of the options make no difference at all...
Just f77, no options (didn't really expect this to work, but what the heck...):
$ f77 blastest.f -o blastest
MAIN blastest:
Cannot open file cblas_f77.h
/usr/bin/f77: aborting compilation
f77 with include option to find the header file. Now, instead it fails on (despite the file name) not being coded with FORTRAN 77 in mind, so the first six columns are nonempty...
$ f77 blastest.f -o blastest -I/usr/include
MAIN blastest:
Error on line 1 of /usr/include/cblas_f77.h: nondigit in statement label field "/* "
Error on line 2 of /usr/include/cblas_f77.h: labeled continuation line (starts " * cbl")
Error on line 3 of /usr/include/cblas_f77.h: labeled continuation line (starts " * Wri")
...
Full output: http://pastebin.com/eZBzh9N5
Switched to gfortran, to be more flexible with the spacing in the header file:
$ gfortran blastest.f -o blastest -I/usr/include
Warning: cblas_f77.h:9: Illegal preprocessor directive
Warning: cblas_f77.h:10: Illegal preprocessor directive
Warning: cblas_f77.h:12: Illegal preprocessor directive
...
Full output: http://pastebin.com/P71Di9pR
OK, so I guessed I need -cpp to get the preprocessor working. That gave exactly the same output as above. Also, if you keep reading you see that the full output, the compiler is still complaining about labelled continuation lines further down...
I believe that you are using the C library "cblas". I would recompile with this command:
gfortran blastest.f -o blastest -L/usr/lib -lblas
and this should sort it all out. I do not believe (though i am not sure) that you need to make use of the "include" statement.
Related
I am trying to build a dll in C++ in which I use a C dll with prototypes like :
int __stdcall foo();.
When linking, the compiler outputs:
Warning: resolving _foo#0 by linking to _foo
Use --enable-stdcall-fixup to disable these warnings
so I added the option when linking, the command looks like:
g++ -std=c++0x -o fooLib.dll fooObj.o -lfooClib --enable-stdcall-fixup -shared
but seems like the g++ doesn't know this option:
g++.exe: error: unrecognized option '--enable-stdcall-fixup'
when I am adding only -enable-stdcall-fixup (one hyphen), it still shows the warnings (looks like has the option has no effect), and the ouput is kind weird:
g++ -std=c++0x -o fooLib.dll fooObj.o -lfooClib -enable-stdcall-fixup -shared
Warning: resolving _foo#0 by linking to _foo
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
ld.exe: warning: cannot find entry symbol nable-stdcall-fixup; defaulting to 679c1000
so does any body know what I am doing wrong ?
g++ --version
g++ (GCC) 4.6.1
Indeed, --enable-stdcall-fixup is not a g++ option. It's a linker option, and you can find it in the ld(1) manpage:
--enable-stdcall-fixup
--disable-stdcall-fixup
If the link finds a symbol that it cannot resolve, it will attempt
to do "fuzzy linking" by looking for another defined symbol that
differs only in the format of the symbol name (cdecl vs stdcall)
and will resolve that symbol by linking to the match. For example,
the undefined symbol "_foo" might be linked to the function
"_foo#12", or the undefined symbol "_bar#16" might be linked to the
function "_bar". When the linker does this, it prints a warning,
since it normally should have failed to link, but sometimes import
libraries generated from third-party dlls may need this feature to
be usable. If you specify --enable-stdcall-fixup, this feature is
fully enabled and warnings are not printed. If you specify
--disable-stdcall-fixup, this feature is disabled and such
mismatches are considered to be errors. [This option is specific
to the i386 PE targeted port of the linker]
gcc is able to recognize some common linker options and pass them on to ld. For example, gcc passes the -llibrary options used to link in library code directly to the linker, as well as an option -e which will be relevant below. Whenever this is the case, it's documented in the gcc(1) manpage.
As you've discovered, this is not the case with --enable-stdcall-fixup, so you'll need to explicitly pass it. In order to pass arbitrary options to the linker, gcc has -Wl. From gcc(1):
-Wl,option
Pass option as an option to the linker. [...]
So in your case, you would call
g++ -Wl,--enable-stdcall-fixup [...]
I don't have the version of the linker mentioned in the manpage, so it still comes up as an unrecognized option for me. But on your system, given that the linker is telling you to use the option, I can only assume it is the version that recognizes it.
As an aside, when you tried calling the option with only one dash, you ran into a red herring. You were actually invoking the -e gcc option that I mentioned above, with the option argument nable-stdcall-fixup. From gcc(1):
-e entry
--entry=entry
Specify that the program entry point is entry. The argument is
interpreted by the linker; the GNU linker accepts either a symbol
name or an address.
So you actually ended up passing an option to the linker saying that, when you execute your program, you want it to begin execution from a function named nable-stdcall-fixup instead of the usual main.
First of all, please read ---PS--- part. This problem is my misunderstanding.
I'm using ubuntu18.04 OS and intel fortran compiler of "parallel studio xe 2020 update 4" ifort.
I have tried to generate dependency among fortran source files using the ifort compiler with the -gen-dep option.
The following simple code was written for my test. The filename is "main.f90".
program main
use mod_a
implicit none
end program main
I executed following command to generate dependency of "main.f90".
ifort -gen-dep -syntax-only main.f90
As a result, I got following error message.
main.f90(2): エラー #7002: コンパイル済みモジュールファイルを開くときのエラーです。INCLUDE パスを確認してください。 [MOD_A]
use mod_a
--------^
The error message notifies that "mod_a.mod" file does not existed yet (while it is written in Japanese).
In the case the "mod_a.mod" has already been generated with compiling mod_a.f90, I got the following "true dependency" with executing above command.
main.o : \
main.f90 mod_a.mod
How can I generate dependency without generating mod_a.mod?
If it exist that the additional ifort options to achieve my goal, I want to know the options with priority.
Thank you for reading.
---PS---
I appologize to everyone who has read this post.
This problem is my misunderstanding.
I tried compiling my "main.f90" program again with ifort -gen-dep -syntax-only main.f90.
program main
use mod_a
implicit none
end program main
As a result, I got following error message and "true dependency".
main.f90(2): エラー #7002: コンパイル済みモジュールファイルを開くときのエラーです。INCLUDE パスを確認してください。 [MOD_A]
use mod_a
--------^
main.o : \
main.f90 mod_a.mod
I don't know why I didn't see this "true dependency", but my goal was already achieved.
However, additionally, I found a another probrem and solved it.
In the case that "main.f90" has huge code which use many subroutines, functions, variables, etc...
ifort -gen-dep -syntax-only main.f90 returned
fatal error: too many errors emitted, stopping now
and didn't return dependency.
To solve this problem, I added the -no-diag-error-limit to ifort command.
You need to supply information about mod_a.
Either compile it beforehand or supply it to the ifort -gen-dep command as such
$ ifort -gen-dep -syntax-only main.f90 mod_a.f90
main.o : \
main.f90 mod_a.mod
mod_a.mod : \
mod_a.f90
mod_a.o : \
mod_a.f90
I am trying to run Ale as my linter, which in turn uses clang-check to lint my code.
$ clang-check FeatureManager.h
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "FeatureManager.h"
No compilation database found in /home/babbleshack/ or any parent directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
/home/babbleshack/FeatureManager.h:6:10: fatal error: 'unordered_map' file not found
#include <unordered_map>
^~~~~~~~~~~~~~~
1 error generated.
Error while processing /home/babbleshack/FeatureManager.h.
Whereas compiling with clang++ returns only a warning.
$ clang++ -std=c++11 -Wall FeatureManager.cxx FeatureManager.h
clang-5.0: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated]
There are no flags to clang-check allowing me to set compilation flags.
Took a while to figure this out, but you can do
clang-check file.cxx -- -Wall -std=c++11 -x c++
or if you are using clang-tidy
clang-tidy file.cxx -- -Wall -std=c++11 -x c++
To get both working with ALE, I added the following to my vimrc
let g:ale_cpp_clangtidy_options = '-Wall -std=c++11 -x c++'
let g:ale_cpp_clangcheck_options = '-- -Wall -std=c++11 -x c++'
If you want ALE to work for C as well, you will have to do the same for g:ale_c_clangtidy_options and g:ale_c_clangcheck_options.
I was getting stumped by a similar error message for far too long:
/my/project/src/util.h:4:10: error: 'string' file not found [clang-diagnostic-error]
#include <string>
^
I saw other questions suggesting that I was missing some critical package, but everything already seemed to be installed (and my code built just fine, it was only clang-tidy that was getting upset).
Passing -v showed that my .h file was being handled differently:
$ clang-tidy ... src/*.{h,cc} -- ... -v
...
clang-tool ... -main-file-name util.cc ... -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9 ... -x c++ ... /tmp/copy/src/util_test.cc
...
clang-tool ... -main-file-name util.h ... -x c-header /my/project/src/util.h
...
As Kris notes the key distinction is the -x c-header flag, which is because clang assumes a .h file contains C, not C++, and this in turn means that the system C++ includes weren't being used to process util.h.
But the -main-file-name flag also stood out to me as odd; why would a header file ever be the main file? While digging around I also came across this short but insightful answer that header files shouldn't be directly compiled in the first place! Using src/*.cc instead of src/*.{h,cc} avoids the problem entirely by never asking Clang to try to process a .h on its own in the first place!
This does introduce one more wrinkle, though. Errors in these header files won't be reported by default, since they're not the files you asked clang-tidy to look at. This is where the "Use -header-filter=. to display errors from all non-system headers.*" message clang-tidy prints comes in. If I pass -header-filter=src/.* (to only include my src headers and not any other header files I'm including with -I) I see the expected errors in my header files. Phew!
I'm not sure whether to prefer -x c++ or -header-filter=.* generally. A downside of -header-filter is you have to tune the filter regex, rather than just passing in the files you want to check. But on the other hand processing header files in isolation is essentially wasteful work (that I expect would add up quickly in a larger project).
I am trying to compile using gfortran using the following:
$ gfortran -I/usr/local/include -O3 -Wall -Wno-uninitialized -fbounds-check -g alignparts_lmbfgs.f90 /home/vincent/test/lmbfgs/Lbfgsb.3.0/lbfgsb.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/linpack.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/blas.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/timer.f /home/vincent/test/lmbfgs/minimal_libraries/imlib2010.a /home/vincent/test/lmbfgs/minimal_libraries/genlib.a -o alignparts_lmbfgs.exe -lfftw3 -lm
but it gave me the error
alignparts_lmbfgs.f90:105: Error: Can't open included file '/usr/include/fftw3.f'
even though I specified the -I opitions where the fftw3.f resides.
What am I doing wrong? I don't have root privileges so I can't just move the files from /usr/local/include to /usr/inlcude
I am a noob in compiling. I am only compiling because this is the only way I am getting the executable. Please be as noob-proof as possible when explaining. Thank you so much!
The compiler reports:
alignparts_lmbfgs.f90:105: Error: Can't open included file '/usr/include/fftw3.f'
This means that your source file alignparts_lmbfgs.f90 contains
a line #105 like:
INCLUDE '/usr/include/fftw3.f'
which tells the compiler to copy the file /usr/include/fftw3.f in place
of that line #105. But there is no such file.
You have passed the compiler option -I/usr/local/include which
tells the compiler to search for included files in /usr/local/include,
and you say:
I specified the -I options where the fftw3.f resides.
So probably there is such a file as /usr/local/include/fftw3.f?
In that case, can change:
INCLUDE '/usr/include/fftw3.f'
to:
INCLUDE '/usr/local/include/fftw3.f'
However, if you do that, then the compiler option:
-I/usr/local/include
is pointless, because /usr/local/include/fftw3.f is an absolute filename:
it either exists or it doesn't.
If you want the program to be compilable independently of the absolute location
of fftw3.f - which is emphatically the best practice - then replace line #105 with:
INCLUDE 'fftw3.f'
Then, if fftw3.f is in fact located in /usr/local/include, you can compile
the program with the option -I/usr/local/include, and in general if the file
is located in directory /look/here/for/headers, you can compile the program
with the option -I/look/here/for/headers.
I have two files -> fact.h and main.c in the /home/snyp1/new folder. main.c has the main function which calls the fact(int x) function in fact.h. I am creating a .a archive with the ar command ->
snyp1#Snyp:~/new$ ar -r -s libfact.a fact.o
ar: creating libfact.a
fact.h fact.o libfact.a main.c
snyp1#Snyp:~/new$ gcc main.c -L/home/snyp1/new -lfact -o main
/home/snyp1/new/libfact.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
snyp1#Snyp:~/new$ ranlib libfact.a
snyp1#Snyp:~/new$ gcc main.c -L/home/snyp1/new -lfact -o main
/home/snyp1/new/libfact.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
I am on ubuntu 12.04. Please let me know whats wrong. (Also, if I don't use the -L/.../new, gcc will say it can't find "lfact", maybe its because its not in /usr/local/lib)
EDIT: OK I have found the cause. Its due to the fact that I was using fact.h to build the fact.o and then putting it in the library, it wasn't working as expected. So I now changed it into file.c and is working fine now. I should have provided that information, I'm sorry. Though I don't know why this kind of problem should arise. Aren't libraries possible to make without at least one .c file in it?
I was using fact.h to build the fact.o and then putting it in the library, it wasn't working as expected.
Do you mean you were compiling fact.h to produce fact.o?
If so, that wasn't doing what you expect. When you invoke gcc on a header file it produces a precompiled header, not an object file. So although you got a file called foo.o it wasn't a valid object file. If you had just run gcc -c fact.h it would have produced a precompiled header fact.gch, but presumably you ran gcc -c fact.h -o fact.o which causes the file to be called fact.o even though it's still a precompiled header. file fact.o would have shown that:
$ file fact.o
fact.o: GCC precompiled header (version 013) for C
You could have forced GCC to treat the file as C code, not a header, by running gcc -x c -c fact.h -o fact.o (the -x c says to treat the input as C code instead of inferring the type from the file extension) but it's probably simpler and less confusing to just name your file correctly instead of trying to compile a header.
Aren't libraries possible to make without at least one .c file in it?
They need at least one object file (i.e. .o file) but you didn't have a valid object, you had a precompiled header misleadingly named as .o, but it was not actually an object file.
if I don't use the -L/.../new, gcc will say it can't find "lfact", maybe its because its not in /usr/local/lib
The linker doesn't only look in /usr/local/lib, there are other default places it looks, but yes, that's basically the problem. Note that you can also say -L. if the library is in the current directory, that's easier than giving an absolute path.
I'm not sure ar supports a dash on anything other than the first option. Try
ar -rs libfact.a fact.o
or just
ar rs libfact.a fact.o
Mind you, I don't know why running ranlib didn't work though.