When I'm compiling a shell script there is this error that is being generated,
"No such file or directoryity.c"
I didn't get why there is no space between directory and the name.
I have a file named "Utlity.c", so I think the trailing part of the error message is taken from there. Please help.
Here's the content of the shell script
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib >> ~/.bashrc
gcc MyFol/main.c MyFol/Utility.c -L /usr/local/lib -lgsl -lgslcblas -lm -o SD
gcc -c -O3 -I /usr/local/include/ ivectTmatC/tmatTrain.c ivectTmatC/Utility.c gfortran tmatTrain.o Utility.o /usr/local/lib/liblapacke.a /usr/local/lib/liblapack.a
/usr/local/lib/librefblas.a /usr/local/lib/libgsl.a /usr/local/lib/libgslcblas.a
-o ivectTmat
g++ cosineKernel/cosineKernel.cpp -L /usr/local/lib -lgsl -lgslcblas -lm -o cosineKerne
Related
During installation of pintos, I had to run make.
Following is the Makefile.
all: setitimer-helper squish-pty squish-unix
CC = gcc
CFLAGS = -Wall -W
LDFLAGS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
In one computer it executed correctly. (output for the command is given below)
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
gcc -lm setitimer-helper.o -o setitimer-helper
gcc -Wall -W -c -o squish-pty.o squish-pty.c
gcc -lm squish-pty.o -o squish-pty
gcc -Wall -W -c -o squish-unix.o squish-unix.c
gcc -lm squish-unix.o -o squish-unix
but in other computer I got the following error
gcc -lm setitimer-helper.o -o setitimer-helper
setitimer-helper.o: In function `main':
setitimer-helper.c:(.text+0xc9): undefined reference to `floor'
collect2: error: ld returned 1 exit status
<builtin>: recipe for target 'setitimer-helper' failed
make: *** [setitimer-helper] Error 1
If looked at first line of outputs of both make commands
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
and
gcc -lm setitimer-helper.o -o setitimer-helper
They are different.
Why make is executing different commands for the same Makefile? and What should I do to remove error?
In the first computer, the setitimer-helper.o file either doesn't exist or the setitimer-helper.c file is newer, so make needs to rebuild it. Thus it runs the compiler, then afterwards it performs the link operation:
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
gcc -lm setitimer-helper.o -o setitimer-helper
On the second computer, the setitimer-helper.o file already exists and is newer than the setitimer-helper.c file, so the compile command was not needed and the second computer proceeded directly to the link line:
gcc -lm setitimer-helper.o -o setitimer-helper
The real question is why you got the linker error on the second computer.
The answer to that is that the -lm flag needs to come on the linker line after the object files. This happens because you added -lm to the LDFLAGS variable which is not the right one: that should contain options that tell the linker where to look for files, etc. (for example, the -L option).
Libraries should be added to the LDLIBS variable, not LDFLAGS. Change your makefile to this:
all: setitimer-helper squish-pty squish-unix
CC = gcc
CFLAGS = -Wall -W
LDLIBS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
Your link line will then look like:
gcc setitimer-helper.o -o setitimer-helper -lm
and should work properly.
I had made a Makefile from Hilton Lipschitz's blog, and made little changes to it in order to generate debug information. Main parts are listed:
CC := clang -arch x86_64
CFLAGS := -c -O0
$(TARGET): $(OBJECTS)
#echo " Linking $(TARGET)"; $(CC) $^ -o $(TARGET) $(LIB)
$(BUILDDIR)/%.o: $(SRCDIR)/%.$(SRCEXT)
#mkdir -p $(BUILDLIST)
#echo "Compiling $<..."; $(CC) $(CFLAGS) $(INC) -o $# $<
debug: CFLAGS += -g
debug: $(TARGET)
Now make runs these commands (paths are summarized with ...):
clang -arch x86_64 -c -O0 -I... -o build/program.o src/program.c
clang -arch x86_64 build/program.o -o bin/program -L...
While make debug runs these commands:
clang -arch x86_64 -c -O0 -g -I... -o build/program.o src/program.c
clang -arch x86_64 build/program.o -o bin/program -L...
The problem is when I execute make or make debug, no program.dSYM subfolder will be made in bin folder. Instead, when I compile without -c argument:
clang -arch x86_64 -g -O0 -I... -L... -o bin/program.o src/program.c
both executable file and .dSYM are created in bin folder.
How can I add debugging information generation feature to this Makefile while separating compiling and linking process?
In which step (compiling/linking) debug information is produced?
UPDATE: I created a GitHub repo and uploaded related Makefile and source to it. To reproduce the problem, please run these commands in your terminal:
git clone https://github.com/hamid914/gdb-lldb-test.git
cd gdb-lldb-test
make debug
The last line, make debug executes these commands:
clang -arch x86_64 -c -O0 -std=c11 -g -I include -I include/libs -I /usr/local/include -o build/program.o src/program.c
clang -arch x86_64 build/program.o -o bin/program -L /usr/local/lib -lm -g
And content of bin folder is:
$ ls bin
program
While if I run clang without -c argument:
clang -arch x86_64 -O0 -std=c11 -g -I include -I include/libs -I /usr/local/include -L /usr/local/lib -lm -o bin/program src/program.c
Contents of bin folder are:
$ ls bin
program program.dSYM
You need to add -g to the linker recipe as well in order to generate .dSYM files, the standard way would be to add
debug: LDFLAGS += -g
but the example you're following defines its own variables for no good reason, it looks like LIB should work however.
I made a custom bash script for assembling, compiling, and linking the kernel but when it gets to the line for linking i run into an error (see below). Im running this on OSX, newest build so im not sure why. Any suggestions?
ld: unknown option: -T
My script:
echo Now assembling, compiling, and linking your kernel:
nasm -f aout -o start.o start.asm
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno- builtin -I./include -c -o main.o main.c
ld -T link.ld -o kernel.bin start.o
echo Done!
Before you try to create your own build scripts, have you managed to get the OSX kernel to build with its own scripts? This site by one of Apple's kernel engineers tells you how it's done.
my mingw compiler: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/threads-posix/sjlj/x32-4.7.2-release-posix-sjlj-rev6.7z
boost: http://sourceforge.net/projects/boost/files/boost/1.52.0/boost_1_52_0.7z
(both on D: drive)
code:
#include <boost\regex.hpp>
int main() {
boost::regex reg("[a-z]+");
}
command line:
SET PATH=%PATH%;D:\mingw\bin;D:\mingw\include
g++ -I "d:\mingw\include" -I "d:\boost" -Os -s -o test.exe test.cpp -std=c++11 -static -L "D:\boost\stage\lib" -lboost_regex
In the d:\boost\stage\lib directory there is libboost_regex-mgw47-mt-1_52.a.
And the process returns :
d:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lboost_regex
collect2.exe: error: ld returned 1 exit status
If I put the exact name of the *.a file the result is cannot find -llibboost_regex-mgw47-mt-1_52.a
even whole path that is -ld:\boost\stage\lib\libboost_regex-mgw47-mt-1_52.a doesn't work. Whatever I put after the -l has the same effect.
As you can see here you must use either (-l followed by the named of the library removing the lib preffix and the extension .a):
g++ -I "d:\mingw\include" -I "d:\boost" -Os -s -o test.exe test.cpp -std=c++11 -static -L "D:\boost\stage\lib" -lboost_regex-mgw47-mt-1_52
or (full path of the library without using -l):
g++ -I "d:\mingw\include" -I "d:\boost" -Os -s -o test.exe test.cpp -std=c++11 -static D:/boost/stage/lib/libboost_regex-mgw47-mt-1_52.a
PS:One thing I personally do is build boost using --layout=tagged. This makes the name of the libraries a lot more manageable (in this case libboost_regex-mt.a).
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