getting following error with the command g++ -o test -L . -l pq
libpq.so: file not recognized: File format not recognized
#file libpq.so
libpq.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), not stripped
gcc version 4.1.2 20070115 (SUSE Linux)
I am getting the same error if I try to use -l dbodbc instead of -l pq.
Note that test.c is a simple hello world program.
Thanks in Advance.
file /usr/bin/g++ tells you that g++ itself is a 64-bit executable, i.e. it runs on a 64-bit machine, it doesn't tell you that g++ can compile 64-bit code (it's very unlikely but it could be a cross compiler for a completely different processor!) Use g++ -v or g++ -dumpmachine to find out what target it generates executables for.
G++ doesn't actually use that library, it just passes the -l option to the linker, so the error is coming from the linker, ld
If ld and objdump are both saying they can't recognize the library but the same file is fine on a different machine, I would try updating or reinstalling the binutils package, which provides both ld and objdump.
You might have a 32-bit binutils installed, so its ld and objdump wouldn't understand the x86_64 library. Ensure you have the 64-bit (i.e. x86_64) binutils RPM installed.
Related
I'm trying to use clang++ as drop-in replacement for G++. I'm compiling for AArch64, but for linking, clang seems to invoke the native (x86) /usr/bin/ld instead of that from AArch64 GCC suite. The clang command line looks like:
clang++ -target aarch64-linux-gnu -v \
-gcc-toolchain /path/to/aarch64/gcc \
--sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc \
<some other options> <obj files>
And from the verbose output, I get:
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: aarch64--linux-gnu
Thread model: posix
Found candidate GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
Selected GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
"/usr/bin/ld" --sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc ...
I don't get why clang got around choosing the native linker. The link fails for obvious reasons that object files are AArch64 ELF. Compilation lines similar to the above, but they go OK.
Any thoughts?
PS: I'm a novice clang user
I managed to find a solution: GCC accepts -B option to point to the search path where it'd try to locate the utilities. It turns out--although not documented--that clang too accepts this option. For me, having -B point to AArch64 binutils solved the problem. Another suggestion was to add the AArch64 binutils in $PATH.
I have two workstations, one of them runs Debian Wheezy and has gcc 4.9.2
Second one runs RHEL 5.5, gcc version is 4.8.2
when I compile the same code with the same options:
$gcc -O3 -DNDEBUG -g -o test test.c
I get all the necessary debugging information on gcc 4.9 on Debian box, however on RHEL box objdump says:
$ objdump --debugging test
test: file format elf64-x86-64
objdump: test: no recognized debugging information
What do I do wrong?
From looking around, this appears to be a known bug or limitation in objdump:
https://bugzilla.redhat.com/show_bug.cgi?id=118383
https://sourceware.org/bugzilla/show_bug.cgi?id=6483
How can I tell if a library was compiled with -g?
Suggested workarounds are using objdump -W, readelf -w, or gcc -gstabs.
I'm trying to compile a 32 bit binary that uses openssl on a debian wheezy 64 bit host.
I've followed what I believe is the recommended approach of adding the i386 architecture and installing libssl1.0.0:i386.
Just a simple test program fails to link:
#include <openssl/ssl.h>
int main(void)
{
SSL_load_error_strings();
return 0;
}
$ gcc -m32 -lssl -o test -Wall test.c
/usr/bin/ld: cannot find -lssl
collect2: error: ld returned 1 exit status
This same command without the -m32 works fine.
I do have a 32 bit libssl:
$ locate libssl | grep i386
/usr/lib/i386-linux-gnu/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/i586/libssl.so.1.0.0
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
Adding --verbose shows the linker command:
/usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id
--no-add-needed --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/32/crtbegin.o
-L/usr/lib/i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/32 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32 -L/lib/i386-linux-gnu -L/lib/../lib32 -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -L/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu -lssl /tmp/ccI9DoNH.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.7/32/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32/crtn.o
This seems to show that it is searching /usr/lib/i386-linux-gnu/, which is where the libssl.so.1.0.0 is.
The files all seem to be valid according to file:
/usr/lib/i386-linux-gnu/libssl.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x56052e2cdbad1207690499400909c6c87209735a, stripped
/usr/lib/i386-linux-gnu/i586/libssl.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x620bde79657c57fe5ef098d3648ccc2ce4bdb232, stripped
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x89b973943dfc314c56231d48eddad5fe785f6b12, stripped
The other thing I thought of trying was installing libssl-dev:i386, but trying to install this wants to remove the 64bit gcc & g++ compilers and the 64bit libssl-dev, which makes me think it's not the right thing to do (and might stop me building 64 bit binaries):
# apt-get install libssl-dev:i386
<..>
The following packages will be REMOVED:
build-essential cpp g++ g++-multilib gcc gcc-multilib libssl-dev lib tool
<..>
I've tried googling around; I've found other people with the same problem, but no solution.
According to askubuntu the debian wheezy libssl-dev package in wheezy is broken / not multi arch compatible. It seems to be fixed in testing (jessie) and possibly also in Ubuntu 14.04 (maybe earlier ubuntu's too).
The following at least fixes the linker error:
cd /usr/lib/i386-linux-gnu/
ln -s libssl.so.1.0.0 libssl.so
ln -s libcrypto.so.1.0.0 libcrypto.so
I have freshly installed Fedora 19 x86_64 on my PC.
I wrote a simple OpenGL program, but failed to compile it.
gcc -o quad quad.c -lX11 -lGL -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.8.1/../.. /../libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /lib/libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
I have MesaGL and other libraries in place (i.e. /usr/lib) then what's wrong ?
For me, something was wrong with the library symlinks:
$ locate libGL.so | egrep ^/usr | xargs file
/usr/lib/libGL.so: symbolic link to `/usr/lib/libGL.so.1'
/usr/lib/libGL.so.1: symbolic link to `/usr/lib/libGL.so.1.2'
/usr/lib/libGL.so.1.2: symbolic link to `/usr/lib/fglrx/fglrx-libGL.so.1.2'
/usr/lib/fglrx/fglrx-libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib64/FGL.renamed.libGL.so.1.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=46121ec8b16424a8b65a0cf11c3f9730ae0e49f5, stripped
/usr/lib64/libGL.so: broken symbolic link to `libGL.so.1.2.0'
/usr/lib64/libGL.so.1: symbolic link to `/usr/lib64/libGL.so.1.2'
/usr/lib64/libGL.so.1.2: symbolic link to `/usr/lib64/fglrx/fglrx-libGL.so.1.2'
/usr/lib64/fglrx/fglrx-libGL.so.1.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
So /usr/lib/libGL.so pointed at a 32-bit lib and /usr/lib/libGL.so was a broken link. I fixed the /usr/lib64 version to point correctly at libGL.so.1 (and the /usr/lib version to point at the 64 bit version for good measure) and this seems to have gotten my code compiling.
There are warnings about incompatible versions of libGL, and also about incompatible GCC libraries. I think you might have a 32 bit version of gcc installed on a 64-bit OS. Try
file -L `which gcc`
to check on this.
The problem is fixed.
I removed ATI Catalyst Driver v13.6 beta by executing "aticonfig --uninstall"
REBOOT
compile the program with same commands, and it was success :)
Now I reinstalled ATI Catalyst Drivers v13.6 beta
REBOOT and compile the program again,
It builds SUCCESSFULLY !!
Don't know what was wrong, but I have OpenGL working now :)
Install freeglut-devel :
# sudo yum install freeglut-devel
I need to link AMD acml library in a C++ project.
I tried to compile it in this way:
g++ mainConsole.cpp -L./acml/pgi64_int64/lib -lacml
but I get this error:
/usr/bin/ld: skipping incompatible ./acml/pgi64_int64/lib/libacml.so when searching for -lacml
/usr/bin/ld: skipping incompatible ./acml/pgi64_int64/lib/libacml.a when searching for -lacml
/usr/bin/ld: cannot find -lacml
What can I do in order to solve?
It seems the linker was told to use a 64 library when the compilation was done using 32 bits.
Your call to g++ will both compile and link. It's easier to debug if you split both. For example:
g++ -I./acml/pgi64_int64/include mainConsole.cpp -o mainConsole.o
g++ -L./acml/pgi64_int64/lib -lacml mainConsole.o -o mainConsole
You can verify the library using file. On my system I get:
$ file /usr/lib/acml/gfortran/libacml.so
/usr/lib/acml/gfortran/libacml.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
The compiled object should be the same:
$ file mainConsole.o
mainConsole.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
The problem is either 32 bits compilation of your own project, or more probably your use of the "int64" verison of ACML. You can read more on int64 here. I suggest you try with the non-int64 version of ACML. For example, instead of downloading acml-5-3-1-pgi-64bit-int64.tgz, download acml-5-3-1-pgi-64bit.tgz.