I am compiling using this command:
icc -O3 MD.c util.c control.c -o MD
and it works fine, but I want to use also the flag -fast
I compile like that:
icc -O3 -fast MD.c util.c control.c -o MD
and I receive the this message:
ld: cannot find -lm
ld: cannot find -lc
ld: cannot find -ldl
ld: cannot find -lc
Do I need to include any library?
P.S.: I am using the compiler
intel-cc-17/17.0.2.174
I think I found the why it doesn't compile.
The command is -Ofast. I used -Ofast and it works fine!
I usually find it in literature as -fast, that's why I used this command initially
Related
I want to create static library and something goes wrong. I have makefile:
static: main.c tree.c
gcc -c -Wall tree.c -o tree.o
ar crs libtree.a tree.o
gcc -Wall -static main.c -L. -ltree -o main
./main
When I write "make static", it shows me:
gcc -c -Wall tree.c -o tree.o
ar crs libtree.a tree.o
gcc -Wall -static main.c -L. -ltree -o main
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [static] Error 1
It created files: tree.o and libtree.a. I don't know why it doesn't want to find a library. Do you know how to solve it?
Most probably, your system is not set up for static linking. Most newer Linux distributions aren't as static linking is highly discouraged.
Look for a package named glibc-static or similar and install.
In case your system is not Linux (could be MacOS X as well, you didn't state that) - You're doomed. Static linking is not supported on that platform at all.
I'm trying to make a relocatable object file with gcc. I use solution from this post. The solution works fine with ld:
$ ld -r a.o b.o -o c.o
However when I try to use it with gcc, the following error happens:
$ gcc -r a.o b.o -o c.o
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Using the -Wl,-r and -Wl,--relocatable options gives the same result.
Is there any way to link relocatable object file with gcc or I'm forced to use ld for doing this?
To solve this problem, the -nostdlib option must also be passed to gcc:
$ gcc -r -nostdlib a.o b.o -o c.o
I don't know it for sure, but it seems without this option gcc tries to link standard libraries into output relocatable object.
I am trying to do something basic, but I can't find the relevant information on how to compile. I tried the following without success:
gfortran testintegral.f90 -lgsl -lgslcblas
testintegral.f90:19.6:
use fgsl
1
Fatal Error: Can't open module file 'fgsl.mod' for reading at (1): No such file
The file is taken from http://de.wikibooks.org/wiki/Fortran:_FGSL#Beispiel:_Numerische_Integration (page in german but readily understandable) so I suppose it is OK.
Maybe the syntax of the compilation command is incorrect ?
EDIT:
I edit my initial post so as not to bury important information in the comments.
Those are the paths of the libraries:
sudo find -name '*libgsl.so*'
./usr/lib/libgsl.so.0
./usr/lib/libgsl.so.0.17.0
sudo find -name '*libgslcblas.so*'
./usr/lib/libgslcblas.so.0
./usr/lib/libgslcblas.so.0.0.0
But I still got an error message when doing:
gfortran testintegral.f90 -L/usr/lib -I/usr/include/fgsl -lfgsl -lgsl -lgslcblas
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
collect2: error: ld returned 1 exit status
Use the -I flag. For example,
gfortran -I/usr/local/fgsl/include testintegral.f90 -lgsl -lgslcblas
All the .mod files in that directory are then included.
EDIT: See also comments below.
Compilation of a file containing modules in gfortran produces two file types: The source file foo.f90 is translated into foo.o. If foo.f90 contains the modules bar and baz, then bar.mod and baz.mod are also generated. They contain the interface information for these modules. Note that there is no required mapping between module and file names (although programming guildelines may require this).
When the statement use fsgl is found, the interface information is read from fsgl.mod. If that file is not found, you get the error message
Can't open module file 'fgsl.mod' for reading at (1): No such file
So, you have to change your order of compilation (possibly through changing a Makefile).
1) the easiest way is
gfortran testintegral.f90 -I/usr/local/include/fgsl -lfgsl
2) this also works
gfortran -I/usr/local/include/fgsl testintegral.f90 -lgsl -lgslcblas -lm
3) I read the log of the make check in the package, the developer used such a way
gfortran -I/usr/local/include/fgsl -g -O2 -c -o test.o testintegral.f90
/bin/bash /path/.../fgsl-1.3.0/libtool --tag=FC --mode=link gfortran -g -O2 -o test test.o /usr/local/lib/libfgsl.la -lgsl -lgslcblas -lm
UPDATE:
First check the linkers for fgsl
pkg-config --libs fgsl
probably will get something like this
-L/usr/local/lib -lfgsl -lgsl -lgslcblas -lm
Then you put the linkers, works for all the cases!
gfortran -I/usr/include/fgsl example.f90 -lfgsl -lgsl -lgslcblas -lm
UPDATE: I answered too soon, here is the best universal method I found:
gfortran `pkg-config --cflags fgsl` testintegral.f90 -o integral `pkg-config --libs fgsl`
I'm trying to create a shared library with my gcc. It's a gcc for vxworks (thats probably the problem...).
I use the gcc as following:
./gcc -shared -B/path/to/gnutools/bin -o test.so test.c
Result:
/path/to/ld: -r and -shared may not be used together
collect2: ld returned 1 exit status
If I try the same with the linux gcc, there's no problem. So i guess the gcc for VxWorks automatically passes the -r (or -i, which is the same and results in the same) flag to the linker. Is there a way to suppress this?
Greetz
marty
PS: making it static is not really an alternative...
Try compile object file separately with -fPIC and then link:
gcc -Wall -fPIC -c -o test.o test.c
gcc -Wall -shared -o test.so test.o
Another suggestion is to use libtool (at least to figure out the correct flags).
A workaround may be to go directly with ld:
ld -shared -o test.so test.o -lc
Having an issue with getting a makefile to find the correct libraries and header files for a .c program I'm trying to compile. I'm trying to compile an open source segmenter for Apple's HTTP Live Streaming and it requires libavformat and other FFMpeg libraries to compile. I used Mac Ports to install FFMpeg and when I run "which ffmpeg" at command line, the directory it shows is opt/local/bin/ffmpeg, but after searching around, this doesn't seem to be the directory with the libraries.
It seems that the libraries are located in opt/local/include because that is where I see the header files. Here is my makefile with the suspected directory:
all:
gcc -Wall -g live_segmenter.c -o live_segmenter -I/opt/local/include -I/opt/local/bin -I/opt/local/include/libavutil -L/opt/local/include/libavformat -libavformat -L/opt/local/include -libavcodec -L/opt/local/include -libavutil -L/opt/local/include -libavcore -lbz2 -lm -lz -lfaac -lmp3lame -lx264 -lfaad -lpthread
clean:
rm -f live_segmenter
And here is the output after trying to compile:
gcc -Wall -g live_segmenter.c -o live_segmenter -I/opt/local/include -I/opt/local/bin -
I/opt/local/include/libavutil -L/opt/local/include/libavformat -libavformat -L/opt/local/include -libavcodec -L/opt/local/include -libavutil -L/opt/local/include -libavcore -lbz2 -lm -lz -lfaac -lmp3lame -lx264 -lfaad -lpthread
ld: library not found for -libavformat
collect2: ld returned 1 exit status
make: *** [all] Error 1
I also tried running "ffmpeg -version" to see if ffmpeg was built correctly and it seems to be so I have run out of ideas on what to do. Any help or point in the right direction would be great. Thank you!
I think you have too many -I and not enough -L. From gcc(1) on Lion:
-I dir
Add the directory dir to the list of directories to be searched for
header files. Directories named by -I are searched before the standard
system include directories. If the directory dir is a standard system
include directory, the option is ignored to ensure that the default
search order for system directories and the special treatment of system
headers are not defeated.
-L dir
Add directory dir to the list of directories to be searched for -l.
-l<libname> is a linker directive that tells ld to include lib<libname> from wherever in the -L directory list.
Try this, instead:
gcc -Wall -g live_segmenter.c -o live_segmenter -I/opt/local/include -L/opt/local/lib -lavcodec -lavutil -lavcore -lbz2 -lm -lz -lfaac -lmp3lame -lx264 -lfaad -lpthread