I am trying to compile Pro*C lib on Linux.I have following code in my make.
etc=$TABS_HOME/admin
export etc
if [ -f ${1}.pc ]
then
rm $1_x.o
compc $1
make -f $etc/proc64.mk $1_x.o
ar -cvq libtabs.a $1_x.o
else
make -f $etc/proc64.mk $1.o
ar -cvq libtabs.a $1.o
fi
Here is the final command that printed when compilation started:
/usr/bin/gcc -g -m64 -g -I/export/home/cl10gr2/oracle/rdbms/public -I/home/med/src/common -I/u01/app/oradb11r2/product/11.2.0/dbhome_3/rdbms/demo -
I/u01/app/oradb11r2/product/11.2.0/dbhome_3/rdbms/public -
I/u01/app/oradb11r2/product/11.2.0/dbhome_3/precomp/public -ltabs.a -lnapi.a -c commonutil_x.c
I am getting following warning/Error:
gcc: -ltabs.a: linker input file unused because linking not done
gcc: -lnapi.a: linker input file unused because linking not done
Can any please help me out why it is not linking the lib files?
Its not linking them because you aren't linking. You are passing the -c option:
-c Compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an object file for each source file.
If you are building intermediate object files, you don't need the libraries until the very end. Include all of the object files and libraries you need in the final stage and link them all together.
Related
Please use following shell commands to reproduce the problem:
# create subdirectory
mkdir subdir
# create source files with dummy functions
echo 'void func1(){}' > file1.c
echo 'void func2(){}' > ./subdir/file2.c
# compiling sources into object files
gcc -c file1.c -o file1.o
gcc -c ./subdir/file2.c -o ./subdir/file2.o
# creating "thin archive" file from object files
ar crT out.a file1.o ./subdir/file2.o
# running objcopy, which leads to an error
objcopy out.a out_copy.a
As a result, following error occurs:
objcopy:st0AENRL/subdir/file2.o: No such file or directory
P.S. Problem with objcopy occurs when "thin" archive is composed of object files from subdirectories.
Does anybody know if such objcopy's behavior is ok?
This is really a bug.
It was reported here.
Support of thin archives was temporary disabled.
gcc has -M-class options (-MMD, -MF, etc.) that allows to generate dependency file during compiling source file. The dependency file contains Makefile rules describing on which source files and headers the generated object file depends on. The dependency file may be included into Makefile and then make will automatically recompile source file when headers are changed.
I need a similar option but for generating dependency file during linking an executable. The dependency file should contain list of libraries used for linking an executable, so if any of libraries is updated, make will re-execute linking of the executable automatically.
I tried to use the same flags (-MMD, -MF), but they doesn't work for linking. It seems they are only for generating dependency files during compiling.
Is there any other flags or means for generating dependency file for executable?
So far I have not found dedicated gcc options for generating dependency file for executable, but found the --trace option (-Wl,--trace when used with gcc). This option generates list of libraries used during linking. Its output has the next format:
gcc -Wl,--trace myprog.c -o myprog -L. -lmylib
-lmylib (./libmylib.a)
-lgcc_s (/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libgcc_s.so)
...
The list of libraries then may be converted to Makefile rules using sed:
echo "myprog: " > myprog.dep
gcc -Wl,--trace myprog.c -o myprog -L. -lmylib \
| sed -n 's/.*(\(.*\)).*/\1 \\/p' >> myprog.dep
So myprog.dep will have the following content:
myprog: \
./libmylib.a \
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libgcc_s.so \
...
This dependency file may be included to Makefile and make will relink myprog if any of libraries are updated.
The dependency file doesn't contain list of object files, but the object files are usually known inside Makefile-script without help of compiler:
myprog: $(OBJS)
gcc -Wl,--trace $^ -o myprog -L. -lmylib | sed -n 's/.*(\(.*\)).*/\1 \\/p' >> myprog.dep
I installed OCaml via OPAM, and by default it uses gcc as the command to compile .c files. For instance, if I run ocamlopt -verbose file.c, I obtain:
+ gcc -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -g
-fno-omit-frame-pointer -c -I'/home/user/.opam/4.02.1+fp/lib/ocaml' 'test.c'
I'd like to change the GCC binary that is used by OCaml, for instance to replace it with gcc-5.1 or /opt/my-gcc/bin/gcc.
Is it possible to do so without reconfiguring and recompiling OCaml? I suppose I could add a gcc alias to a directory in the PATH, but I'd prefer a cleaner solution if there is one.
To check if gcc was not chosen based on a textual configuration file (that I could easily change), I searched for occurrences of gcc in my /home/user/.opam/4.02.1+fp directory, but the only occurrence in a non-binary file that I found was in lib/ocaml/Makefile.config, and changing it does nothing for the already-compiled binary.
ocamlopt uses gcc for three things. First, for compiling .c files that appear on the command line of ocamlopt. Second, for assembling the .s files that it generates internally when compiling an OCaml source file. Third, for linking the object files together at the end.
For the first and third, you can supply a different compiler with the -cc flag.
For the second, you need to rebuild the OCaml compiler.
Update
Here's what I see on OS X when compiling a C and an OCaml module with the -verbose flag:
$ ocamlopt -verbose -cc gcc -o m m.ml c.c 2>&1 | grep -v warning
+ clang -arch x86_64 -c -o 'm.o' \
'/var/folders/w4/1tgxn_s936b148fdgb8l9xv80000gn/T/camlasm461f1b.s' \
+ gcc -c -I'/usr/local/lib/ocaml' 'c.c'
+ clang -arch x86_64 -c -o \
'/var/folders/w4/1tgxn_s936b148fdgb8l9xv80000gn/T/camlstartup695941.o' \
'/var/folders/w4/1tgxn_s936b148fdgb8l9xv80000gn/T/camlstartupb6b001.s'
+ gcc -o 'm' '-L/usr/local/lib/ocaml' \
'/var/folders/w4/1tgxn_s936b148fdgb8l9xv80000gn/T/camlstartup695941.o' \
'/usr/local/lib/ocaml/std_exit.o' 'm.o' \
'/usr/local/lib/ocaml/stdlib.a' 'c.o' \
'/usr/local/lib/ocaml/libasmrun.a'
So, the compiler given by the -cc option is used to do the compilation of the .c file and the final linking. To change the handling of the .s files you need to rebuild the compiler. I'm going to update my answer above.
I'm trying to compile a program using a third party library, Omnet++ in my case. Apparently "make" does not find a library, but the path it uses is correct as you can see (in the sense that I can see the library under omnet++ source tree)
pv135168:basic Bob$ opp_makemake
Creating Makefile in /Users/Bob/Code/network_sim/basic... Makefile created, running "make depend" to add dependencies... opp_makedep -Y --objdirtree -I. -f Makefile -P\$O/ -- ./*.cc
pv135168:basic Bob$ make
g++ -c -g -Wall
-fno-stack-protector -m32 -DHAVE_PCAP -DXMLPARSER=libxml
-DWITH_PARSIM -DWITH_NETBUILDER -I.
-I/Users/Bob/Code/omnetpp-4.1/include -o out/gcc-debug//txc1.o txc1.cc g++ -m32 -Wl,-rpath,/Users/Bob/Code/omnetpp-4.1/lib -Wl,-rpath,. -o out/gcc-debug//basic out/gcc-debug//txc1.o -Wl,-all_load
-L"/Users/Bob/Code/omnetpp-4.1/lib/gcc"
-L"/Users/Bob/Code/omnetpp-4.1/lib" -u _tkenv_lib -lopptkenvd
-loppenvird -lopplayoutd -u _cmdenv_lib -loppcmdenvd -loppenvird
-loppsimd -lstdc++
ld: library not found for -lopptkenvd
collect2: ld returned 1 exit status make: *** [out/gcc-debug//basic]
Error 1 pv135168:basic Bob$
It's looking in the following directories for a file called libopptkenvd.dylib or libopptkenvd.a:
/Users/Bob/Code/omnetpp-4.1/lib/gcc
/Users/Bob/Code/omnetpp-4.1/lib
Is that file in one of those directories (or in the standard directories like /usr/lib)? I don't see an indication of that in your output.
I was trying to do something like this in a makefile:
program.exe: ui.o main.o
gcc ......etc
ui.o: window1.o window2.o
gcc -c window1.o window2.o -o ui.o #this doesn't want to work
window1.o: window1.c window1.h window1_events.c window1_controls.c ...
gcc -c window1.c window1_events.c window1_controls.c... -o window1.o
window2.o: ...
gcc ...
main.o: ...
gcc ...
but when I compile like this, it gives the error "input file unused because linking not done," and then I get a bunch of unresolved externs, etc--problems which are resolved by changing
program.exe: ui.o main.o
gcc ...
to
program.exe: window1.o window2.o main.o
gcc ...
so is it possible to just link object files together, to avoid having mile-long lines in a makefile and break down the build process a little more?
Yes: to merge several object files into one, use ld -r or ld -Ur:
From "man ld" on Linux:
-r
--relocatable
Generate relocatable output---i.e., generate an output file that can
in turn serve as input to ld. This is often called partial linking.
As a side effect, in environments that support standard Unix magic
numbers, this option also sets the output file’s magic number to
"OMAGIC".
If this option is not specified, an absolute file is produced.
When linking C++ programs, this option will not resolve references to
constructors; to do that, use -Ur.
You could also do this with gcc:
gcc -Wl,-r foo.o bar.o -o foobar.o -nostdlib
Merging object files like this has some advantages over using an archive library: if merged files change very infrequently (compared to say main.c), your final executable links will be faster.
OTOH, with archived library, the linker will only use what it needs, so your executable may end up being smaller if e.g. window2.c ends up not being necessary.
I bunch of object files is a library. You can create a library with the ar
utility. The following example creates a library called mylib.a containing the files foo.o and bar.o
ar rvs mylib.a foo.o bar.o
You can then link with it by using it on the compiler command line:
gcc -o myexe main.c mylib.a
To create a library:
ar rvs somelib.a file1.o file2.o file3.o
To link it:
gcc -o program.exe file4.o somelib.a