compile using gcc that the compiled code be saved with a different name and run it. I need the commands
To compile file.c and create executable file do
gcc -Wall -Werror -o file file.c
If you need additional libraries, add them after the C file.
To run the program do
./file
Related
I would like to "quickly" deploy a shared library on my Ubuntu. It is for a short term project so I don't want to use auto-tools here, but do everything manually.
So I built my library with this:
%.o: %.c
$(CC) -fPIC -c $(CFLAGS) -o $# $< -MMD -MF $(#:.o=.d)
lib%.so: %.o | dist
$(CC) -shared -o dist/$# $^
dist:
mkdir -p dist
install: lib
mkdir -p $(PREFIX)/lib/foobar
mkdir -p $(PREFIX)/include/foobar
cp dist/*.so $(PREFIX)/lib/foobar
cp dist/*.h $(PREFIX)/include/foobar
ldconfig $(PREFIX)/lib/foobar/
In another project, I would like to use libfoo.so now located in /usr/lib/foobar/libfoo.so. So I've built it with:
$(CC) test.c -lfoo
Unfortunately I have this issue:
/usr/bin/ld: cannot find -lfoo
I now that I can do -L/usr/lib/foobar/libfoo.so but this location should be known by my operating system.
Am I forced to put it directly into /usr/lib? I have the same issue with /usr/local/lib which doesn't seem to be the default route to be used with gcc ... -l...
How should I normally deploy a shared library?
The list of directories from ld.so.conf has system-wide impact; the runtime linker will search those dirs when starting any dynamic binary. Unless you actually want additional system-wide overhead, it's more efficient to privately search another dir on a custom / as-needed basis. Private-search is ideally suited for cases of 1-off or single-use or rarely-used custom libs.
For the 1 or few bins that reference those libs, bins can be rebuilt with a directive for the runtime linker to privately search 1+ custom dirs; eg:
gcc -L/usr/local/lib64 -Wl,-rpath=/usr/local/lib64 -lblah
For more details, see gcc and ld manual pages for the respective options -Wl, and -rpath.
To make a directory known to the dynamic linker (ld.so) so that it can be found at run-time without depending on LD_LIBRARY_PATH:
list it in /etc/ld.so.conf (or in an include file under /etc/ld.so.conf.d, if the main /etc/ld.so.conf file has an appropriate include statement to enable this)
then run /sbin/ldconfig
As regards the build-time linker (ld), it is normal to expect to have to specify the library location explicitly using the -L flag on the compiler, normally with the directory as argument e.g. -L/usr/lib/foobar. However, according to the manual page for the compile-time linker, ld, the search path for libraries does contain (after everything else) the directories referenced by /etc/ld.so.conf. So although ld.so.conf is primarily intended for use with the run-time linker as the name suggests, the build-time linker will in fact find your library once you have listed the directory there.
In this Linux manual is written that make is:
a utility for building and maintaining groups of programs (and other
types of files) from source code.
Description The purpose of the make utility is to determine
automatically which pieces of a large program need to be re-compiled,
and issue the commands necessary to recompile them.
What does automatic determination mean here? What is the principal/significant difference between running make or just running ./build.sh where I have my build scripts?
What is the principal/significant difference between running make or just running ./build.sh where I have my build scripts?
make can be easily used in such a way that it only rebuilds what needs to be rebuilt (and nothing more than that).
Comparative example
Consider a project to be built, program, consisting of the following files:
main.c
foo.c
bar.c
foo.h
bar.h
For this discussion, let's assume that foo.c and bar.c only include (i.e.: depend on) foo.h and bar.c, respectively.
With a build.sh script which simply consists of commands for building a software like the following:
gcc -c foo.c
gcc -c bar.c
gcc -c main.c
gcc foo.o bar.o main.o -o program
If just foo.h gets modified, this project needs to be rebuild. With this approach, this will be done by re-running build.sh, which compiles all the source files. Note, that neither bar.o nor main.o would actually need to be generated again, since the files bar.c, bar.h, main.c didn't changed and they don't depend on foo.h at all (i.e.: they are not affected by a change in foo.h).
With make however, if used properly, a dependence graph is generated, so that only the files that need to be updated would be generated again: in this case foo.c and program.
That relies on the dependency relationship between the source files and object files (among other things) being properly specified to make. This is achieved by means of a makefile:
program: main.o foo.o bar.o
gcc -o $# $^
foo.c: foo.h
bar.c: bar.h
Basically, it is explicitly specifying that:
program depends on main.o, foo.o and bar.o.
foo.c depends on foo.h.
bar.c depends on bar.c.
and implicitly:
main.o depends on main.c
foo.o depends on foo.c
bar.o depends on bar.c
That way, make knows what has to be rebuilt or updated whenever something changes and it updates only that instead of building everything from scratch.
For example, I've got a 'b.c' file, I compile and generate the code, while I wish to see an intermediate assembly file, I can do under shell like this:
gcc -S b.c
gcc -c b.c
gcc b.o -o b
My question is, how to specify inside scons SConstruct, with all these steps, to make sure I get b.s, b.o and 'b' executable? Seems scons only support functions like Program, Object, Library, so I only get b.o and 'b'. But how to make out 'b.s', while I don't wish to introduce any duplicated work by the compiler(to save time).
Thanks.
I'm new in linux trying to run .C program from another directory in script. script is in home directory and .C program is in Desktop directory. here is script.
#!/bin/bash
chmod 777 myscript
cd /home/unifi-007/Desktop/
gcc main -o main.c
./main
But i'm not getting it right. how to execute main.c in script.
The usage of gcc is clearly wrong, it should be gcc -o main main.c.
BTW, .C is a suffix for C++ (at least for GCC it is), not C.
BTW again, normally, you do not run a C source file, you compile it, and run the executable file generated by compiler (by linker, actually).
I have the usual gcc on my machine (at /usr/bin/gcc), and another one (newer) is linked when I setup the environment for a certain framework which I'm working on.
And I would like to compile with the old one I have on /usr/bin/gcc, instead of using the newer one.
I have to use "gmake" command for the compilation (custom compilation setup).
Without changing the PATH, how could I "tell" gmake to use a different gcc?
from command line:
gmake CC=/usr/bin/gcc
Use
make CC=/opt/bin/my-gcc
And make sure that for compilation you use $(CC) instead of direct gcc:
foo.o: foo.c
$(CC) -c foo.c -o foo.o
If you use default compilation patters the gmake uses CC variable by default
In your makefile, define a variable for your preferred compiler.
CC=/usr/bin/gcc
And after your target, use the variable.
a.o : a.c
$(CC) ...