Could anyone explain me (in plain English) how to link the Vector Statistical Library (included in the Math Kernel Library) to a Fortran 90 source code compiling with Intel Fortran compiler for Linux?
My makefile looks as follows:
f90comp = ifort
libdir = /home/project/
mklpath = /opt/intel/mkl/10.0.5.025/lib/32/
mklinclude = /opt/intel/mkl/10.0.5.025/include/
exec: AAA.o
$(f90comp) -o AAA -L$(mklpath) -I$(mklinclude) AAA.o -libmkl_ia32.a -lguide -lpthread
AAA.o: $(libdir)AAA.f90
$(f90comp) -c -L$(mklpath) -I$(mklinclude) $(libdir)AAA.f90 -libmkl_ia32.a -lguide -lpthread
It produces the following error:
ld: cannot find -libmkl_ia32.a
make: *** Error 1
However, the file exists in the specified directory (mklpath).
Thanks!!
How is the file really called? -l to the linker is not meant to take a real file name. It is meant to take [x], while the file to be found then is called lib[x].{so,a}.
If you want to give the real object file name, you may either just append it without using -l and using the absolute path, or use -l:[filename].
I assume the right way to do it for you is -lmkl_ia32 however. Raw filenames are only useful if the lib is not called lib[x].{so,a}
Related
I am trying to compile the gjh solver - written in C - into an executable file in windows. It is available on netlib
I downloaded the c file and am using gcc compiler via WinGW on windows' command prompt. Trying to compile the gjh.c file directly gave me an error that says:
gjh.c:33:21: fatal error: getstub.h: No such file or directory
#include "getstub.h"
compilation terminated.
I assumed that compiling gjh.c requires the dependency getstub.h.
getstub.h is not the only dependency required, there are other dependencies, namely: arith.h, asl.h, funcadd.h, and stdio1.h. All of these files are available on the same link where I found getstub.h. However, arith.h0 and stdio1.h0 are available instead of arith.h and stdio1.h.
Are these files the same? I tried to rename the .h0 files to .h and tried to compile gjh.c, but I got this error:
collect2.exe: error: ld returned 1 exit status
Are the two files the same? If not, is there any way for me to compile the gjh solver successfully into an .exe?
If that's the only problem in compiling, try using the -I switch in gcc:
gcc -I/my/path/to/include/files -o gjh gjh.c
the -I switch hints to gcc where to find your #include files.
I am not sure about the stdio1.h. I think your approach to rename is OK but that reference to external functions such as Sprintf. You need to link with a library defining that. If you know where it comes from, use the -L and -l switch in gcc for that:
gcc -I/my/path/to/include/files -L/my/path/to/library -lnameoflibrary \
-o gjh gjh.c
I'm trying to execute the below program-
Within APUE.3E -> filedir -> filetype.c (this comes by default when I downloaded APUE.3E. I didn't make any changes)
but when I compile this is the error I'm receiving:
myramya~/Documents/apue.3e/filedir$ gcc filetype.c -lm -o filetype
/tmp/cchPKE7K.o: In function main':
filetype.c:(.text+0x94): undefined reference to err_ret'
collect2: error: ld returned 1 exit status
I'm using Linux Ubuntu. I have installed APUE.3E in Documents folder. I have administrator permissions. I wrote a simple Hello.c program and executed using:
$ gcc hello.c -o hello
and it worked without any issues.
Your hello example works compiling in a single step with gcc because it does not call any functions in other files (except functions in the standard C library which allways gets linked in).
Your filetype.c makes calls to a function err_ret which is not within filetype.c but in some other source file.
When compiling bigger programs the work is usually done in two steps: First source files are compiled into object files by making one call to gcc with the flag -c for each source file. Then all object files are linked together with a single call to gcc with all object files. It is also possible to put object files together into libraries. Usually a Makefile is used to compile bigger projects.
Your specific case with apue.3e is well explained here: https://unix.stackexchange.com/questions/105483/compiling-code-from-apue
I have a question to a specific F77 library. Its name is libminuit. One can download it from -> https://github.com/ramos/minuit/downloads. It supplies methods to fit a theoretical model to experimental data.
The download consists of the F77 source code (many files) and a makefile. The makefile is to produce the library.
I wrote a chi squared function in f95 code and want to use the minuit library to do the minimization.
Its the first time for me using fortran at all. I produced the library first using the F77 compiler and afterwards using the F95 compiler.
In both cases the library does not get found.
The whole process from producing the library until the compilation and linking is:
$ gfortran -c *.F
$ ar rcs libminuit.a *.o
$ cp libminuit.a /home/kai/TEST/f95/lib/libminuit.a
$ rm *o *a
$ nano testM.f90
$ gfortran testM.f90 -L/home/kai/TEST/f95/lib -libminuit
/usr/bin/ld: cannot find -libminuit
collect2: error: ld returned 1 exit status
$ cat testM.f90
Test source:
PROGRAM TESTM
call minuit(5,6,7)
END PROGRAM TESTM
When linking to a library named libfoo.a you need to pass the flag -lfoo to the compiler, not -llibfoo. So in your case you should use -lminuit, not -libminuit.
With gcc in ubuntu I used this command to compile my source code:
gcc 1.c -L. -lagent -lm -lpthread -o 1
but I got this error:
/usr/bin/ld: skipping incompatible ./libagent.so when searching for -lagent
/usr/bin/ld: cannot find -lagent
collect2: ld returned 1 exit status
How can I solve this?
The linker is telling you that the file ./libagent.so exists, but isn't in the appropriate format.
It could be an empty file, or built for 32-bit instead of 64-bit, or it could be a symlink pointing to the wrong version.
Let's look at your command line parameters first.
gcc 1.c -L. -lagent -lm -lpthread -o 1
You call the compiler gcc with the input source code of 1.c and then you specify an additional (link) library path to include the current directory (.) -L.. Then you tell it to link against the agent and pthread libraries, where shared (dynamic) libraries have the default name format of libNAME.so where NAME is replaced with the name. Static libraries have the default file extension .a (from the term archive). Then you specify the output (executable in this case) to be the file 1 (digit one, not the letter 'ell').
/usr/bin/ld: skipping incompatible ./libagent.so when searching for -lagent
This is the linker (ld) telling you that the file ./libagent.so (it found presumably in the current directory) is not a valid shared library format as it was expecting. This could be for a different machine architecture (x86-64, ARMle, PowerPC, MIPS) or a incompatible library format (I don't know if library files, .so, have any COFF or ELF or PE dependencies or not). Or simply otherwise empty or corrupted (e.g. interrupted output due to errors compiling / linking).
So you normally want to not include your current directory in your linker's search path, unless you have the copy of the library that you have not yet installed (typically to /usr/lib/ or /usr/local/lib/), such as you wrote the library and wish to link test programs to it before you install it.
Debian and Unbuntu-oriented part of the answer:
Normally you want to install shared library's runtime component (often named something like libagent) and the associated development files (most often at least a header file and hopefully a manpage) in the format libagent-dev. RPM based Linux systems use libagent-devel style naming conventions (from memory). So sudo aptitude install libagent-dev should do the trick if that is the package's name.
i'm new on gcc compiler.
My friend wrote this script (graphic filter) for me but i can't use it because i receive some error.
I have 2 directory and a C file:
-dir- include --> basics.h common.h freeimage.h hqx.h imageIO.h pcxIO.h
-dir- lib --> libfreeimage-3.13.1.so libfreeimage.a libfreeimage.so.3 libhqx.a libhqx.so libhqx.so.1 libhqx.so.1.0.0
scaling.c
i try to compile with this command:
gcc scaling.c -I./include -L./lib -lm -lfreeimage -lhqx -lstdc++ -o filter
But i receive this error:
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/bin/ld:./lib/libhqx.so: file format not recognized; treating as linker script
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/bin/ld:./lib/libhqx.so:1: syntax error
collect2: ld returned 1 exit status
Thanks in advance and sorry for my english.
The linker will treat any file that doesn't look like an object file or library as a linker script containing commands to specify how linking should be done. Things like load addresses, section definitions, etc.
Apparently libhqx.so doesn't look like a shared library on you system. I assume it was built on your friend's system?
To get a clue about what the file is, use the file command. You should get something like:
main% file /lib/libc-2.11.2.so
/lib/libc-2.11.2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
If not, you'll have to build or find a library compatible with your system.
I had a similar problem yesterday, and I think your libhqx.so was a symbolic link to libhqx.so.1.0.0 or to libhqx.so.1 in your friend's machine, and when you copied this files, this link had broken. (at least that was the situation in our system, and the problem solved after we remove the .so file, and create the right symbolic link)