I got the following error when I try nasm with gcc (both with -m32 and without it). Does anybody know how to fix the problem? Thanks.
~$ cat tiny.asm
BITS 32
GLOBAL main
SECTION .text
main:
mov eax, 42
ret
~$ nasm -f elf tiny.asm
~$ gcc -Wall -s tiny.o
/usr/bin/ld: i386 architecture of input file `tiny.o' is incompatible with i386:x86-64 output
collect2: error: ld returned 1 exit status
$ gcc -m32 -Wall -s tiny.o
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
Related
I am building foo.so and that depends on bar.so. They will both be installed in the same location /some/lib, with the RUNPATH set appropriately to /some/lib. But they are built from different directories.
I'm trying to build them like:
cd /tmp/bar
gcc -o bar.o -c bar.c
ld -Bshareable -o bar.so bar.o
cd /tmp/foo
gcc -o foo.o -c foo.c
ld -Bshareable -rpath /some/libs -o foo.so foo.o ../bar/bar.so
ldd foo.so
But the problem is that ldd shows ../bar/bar.so. I can fix it by doing:
cd /tmp/bar
gcc -o bar.o -c bar.c
ld -Bshareable -o bar.so bar.o
cd /tmp/foo
gcc -o foo.o -c foo.c
cp ../bar/bar.so .
ld -Bshareable -rpath /some/lib -o foo.so foo.o bar.so
ldd foo.so
Now the ldd just show plain bar.so, which is right. But is there a better way that doesn't require copying or symlinking bar.so just for the link step?
Solution:
ld -Bshareable -rpath /some/lib -L../bar -o foo.so foo.o -l:bar.so
works without needing to copy bar.so to the current directory.
My application can be compiled & linked successfully via GCC/G++ 4.4.7, which is shipped with CentOS 6.5.
I wanna static link libstdc++.a via -static-libstdc++ , but it is not supported by 4.4.7.
Hence I installed redhat-devtools-1.1 via the following command, upgraded GCC/G++ to 4.7.2
cd /etc/yum.repos.d
wget http://people.centos.org/tru/devtools-1.1/devtools-1.1.repo
yum --enablerepo=testing-1.1-devtools-6 install devtoolset-1.1-gcc devtoolset-1.1-gcc-c++
Then compile my application with the new toolset, it fails
/opt/centos/devtoolset-1.1/root/usr/bin/c++ -m64 -c -O2 -Iinc -fPIC -MMD -MP -MF "AutoInit.o.d" -o AutoInit.o AutoInit.cpp
/opt/centos/devtoolset-1.1/root/usr/bin/gcc -m64 -c -O2 -D_LARGEFILE64_SOURCE=1 -Iinc -std=c99 -fPIC -MMD -MP -MF "common.o.d" -o common.o common.c
/opt/centos/devtoolset-1.1/root/usr/bin/gcc -m64 -c -O2 -D_LARGEFILE64_SOURCE=1 -Iinc -std=c99 -fPIC -MMD -MP -MF "rpc.o.d" -o rpc.o rpc.c
/opt/centos/devtoolset-1.1/root/usr/bin/gcc -m64 -c -O2 -D_LARGEFILE64_SOURCE=1 -Iinc -std=c99 -fPIC -MMD -MP -MF "transport_service.o.d" -o transport_service.o transport_service.c
/opt/centos/devtoolset-1.1/root/usr/bin/gcc -m64 -c -O2 -D_LARGEFILE64_SOURCE=1 -Iinc -std=c99 -fPIC -MMD -MP -MF "interop.o.d" -o interop.o interop.c
/opt/centos/devtoolset-1.1/root/usr/bin/gcc -m64 -c -O2 -D_LARGEFILE64_SOURCE=1 -Iinc -std=c99 -fPIC -MMD -MP -MF "utility.o.d" -o utility.o utility.c
/opt/centos/devtoolset-1.1/root/usr/bin/g++ -o libmq.so AutoInit.o common.o rpc.o transport_service.o interop.o utility.o -L./lib -l:libapr-1.a -l:libcurl.a -l:libjansson.a -static-libgcc -static-libstdc++ -Wl,--start-group -l:libzmq.a -l:libczmq.a -Wl,--end-group -shared -fPIC
/usr/bin/ld: /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/libstdc++.a(compatibility.o): relocation R_X86_64_32 against `_ZTIN10__cxxabiv115__forced_unwindE' can not be used when making a shared object; recompile with -fPIC
/opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/libstdc++.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
Please do you know how to resolve this problem?
Likely libstdc++.a is compiled without -fPIC so ld prohibites building a shared object with it. http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/ . Probably you need to recompile libstdc++.a yourself.
Even though I have linked -lrt in my Makefile, as you can see below, I am still getting undefined reference to 'mq_open'. Please help!
all:get1 iserv1
get: get1.c
gcc -Wall -o get1 get1.c -lrt
iserv: iserv1.c
gcc -Wall -o iserv1 iserv1.c -lrt
clean:
rm -fr *~ get1 iserv1
Note -lrt should be at end not inbetween.
Your makefile is wrong
all:get1 iserv1
get: get1.c
gcc -Wall -o get1 get1.c -lrt
all has a prerequisite of get1 and iserv1. But you created a get target and an iserv target. So e.g. get1 will be compiled with the default make rules, which does not include -lrt (this should show if you look at the gcc commands that actually are executed.)
Your makefile should like like this:
all:get1 iserv1
get1: get1.c
gcc -Wall -o get1 get1.c -lrt
iserv1: iserv1.c
gcc -Wall -o iserv1 iserv1.c -lrt
clean:
rm -fr *~ get1 iserv1
I have used this command.
libtool --mode=compile gcc -g -o -c foo.c
Actual output should be like this after the command:
$libtool --mode=compile gcc -g -O -c foo.c
mkdir .libs
gcc -g -O -c foo.c -fPIC -DPIC -o .libs/foo.o
gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1
but observed output is
$libtool --mode=compile gcc -g -O -c foo.c
gcc -g -O -c foo.c -fPIC -DPIC -o .libs/foo.o
gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1.
.libs directory is not creating. It there any changes i have to make
http://www.gnu.org/software/libtool/manual/html_node/Creating-object-files.html
On shared library systems, libtool automatically generates an additional PIC object by inserting the appropriate PIC generation flags into the compilation command:
burger$ libtool --mode=compile gcc -g -O -c foo.c
mkdir .libs
gcc -g -O -c foo.c -fPIC -DPIC -o .libs/foo.o
gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1
burger$
Note that Libtool automatically created .libs directory upon its first execution, where PIC library object files will be stored.
Since ‘burger’ supports shared libraries, and requires PIC objects to build them, Libtool has compiled a PIC object this time, and made a note of it in the libtool object:
# foo.lo - a libtool object file
# Generated by ltmain.sh (GNU libtool) 2.4.2
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# Name of the PIC object.
pic_object='.libs/foo.o'
# Name of the non-PIC object.
non_pic_object='foo.o'
Notice that the second run of GCC has its output discarded. This is done so that compiler warnings aren't annoyingly duplicated. If you need to see both sets of warnings (you might have conditional code inside ‘#ifdef PIC’ for example), you can turn off suppression with the -no-suppress option to libtool's compile mode:
burger$ libtool --mode=compile gcc -no-suppress -g -O -c hello.c
gcc -g -O -c hello.c -fPIC -DPIC -o .libs/hello.o
gcc -g -O -c hello.c -o hello.o
burger$
I hope this would be helpful.
Thanks & Regards,
Alok
I have a very small make file with content
VPATH = src
main: main.o
gcc -o main main.o
main.o: main.c
gcc -c main.c
Current directory contains a directory src which contains main.c
When I execute make, I get error
gcc -c main.c
gcc: main.c: No such file or directory
gcc: no input files
make: *** [main.o] Error 1
When I move main.c in the current directory, it works. It seems VPATH macro is not working. Please let me know the usage of VPATH.
While make locates main.c just fine, you are missing the use of the automatic variables here:
main.o : main.c
gcc -o $# -c $<
which will be expanded by make to the gcc call
gcc -o main.o -c src/main.c
Always use the automatic variables $< (first prerequisite) and $# (target) where you can, they make make both more powerful and easier to read.