This works:
cc leveldb_ext.cc leveldb_object.cc -o leveldb.so -I /usr/include/python2.7 -lpython2.7 -lleveldb -lsnappy -shared -lc
This does not work:
cc -I /usr/include/python2.7 -g -c leveldb_ext.cc leveldb_object.cc
ld -shared -o leveldb.so -lpython2.7 -lleveldb -lsnappy leveldb_ext.o leveldb_object.o -lc
In both cases, I don't get any compiler/linking errors. However, when trying to import it, I get this error:
$ python -c "import leveldb"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: ./leveldb.so: undefined symbol: _ZNK7leveldb6Status8ToStringEv
Why? Is there any difference between the two methods? What is the difference?
The order of the object files and the libraries is not the same between the two cases. The order is significant.
Usually a setup.py script is used to compile Python modules. Something like this should work:
from setuptools.extension import Extension
ext_modules = [
Extension(
'yourmodule',
sources=['yourmodule.c'],
libraries=['a', 'b', 'c'],
extra_compile_args=['-Wall', '-g'],
)
]
setup(..., ext_modules=ext_modules)
Setuptools makes sure the compiler and linker will be called with the right flags, avoiding issues like the one in your question.
Btw, you should have a look at Plyvel if you want a nice Python API for LevelDB. See https://github.com/wbolster/plyvel and https://plyvel.readthedocs.org/ for more information. (Disclaimer: I'm the author.)
Related
I am trying to create a conda package that includes c code that have to compile with -lz. However, when the package is building, ld cannot find zlib even though I provide it with any paths possible.
As I understand, conda creates almost empty environment, and then fills it with necessary libraries and tools. It also installs zlib, so that there is zlib.h in $BUILD_PREFIX/include/ and libz.so, libz.a in $BUILD_PREFIX/lib.
Compilation itself looks like
$BUILD_PREFIX/bin/x86_64-conda_cos6-linux-gnu-cc -fPIC -g -Wall -O2 -Wc++-compat main.o -o <name> -L. -l<name> -lm -lz -lpthread
x86_64-conda_cos6-linux-gnu-cc is gcc version 7.3.0, and it calls ld defined here as $BUILD_PREFIX/bin/x86_64-conda_cos6-linux-gnu-ld. Then ld falls with an error cannot find -lz.
I tried using
export C_INCLUDE_PATH="$BUILD_PREFIX/include"
export LIBRARY_PATH="$BUILD_PREFIX/lib"
export LD_LIBRARY_PATH="$BUILD_PREFIX/lib"
export LD_PRELOAD="$BUILD_PREFIX/lib/libz.so"
in any combinations, but that did not work.
Are there any other ways to show ld path to the library?
I have the following .sh file (from here).
g++ -c -pipe -g -std=gnu++11 -Wall -W -fPIC -I. -I./tensorflow
-I./tensorflow/bazel-tensorflow/external/eigen_archive -I./tensorflow/bazel-tensorflow/external/protobuf/src -I./tensorflow/bazel-genfiles -o main.o ./main.cpp
g++ -o Tutorial main.o -L./tensorflow/bazel-bin/tensorflow
-ltensorflow_cc
cp ./tensorflow/bazel-bin/tensorflow/libtensorflow* .
When I try to run this .sh file from terminal I got an error. Therefore I executed the commands one by one. First one worked fine and I saw that when I run the second command ( g++ -o Tutorial main.o -L./tensorflow/bazel-bin/tensorflow
-ltensorflow_cc) I get the following error.
/usr/bin/ld: main.o: undefined reference to symbol '_ZN10tensorflow3Env19NewRandomAccessFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPSt10unique_ptrINS_16RandomAccessFileESt14default_deleteISA_EE'
libtensorflow_framework.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I saw the answer here and I see it as closely related to mine. But I cannot figure out how to adapt it to my problem.
Can someone please help with this?
The linker is saying that the linkage requires shared library libtensorflow_framework.so (presumably because -ltensorflow_cc depends on it and requests it) but is not given in your commandline. This should be solved by adding -ltensorflow_framework at the end, with an additional -L option if necessary.
I was too getting the same error.
If you are using tensorflow 2, then you need to link .so.2 files. You should find them in the bazel build directory. For me it is :
/tmp/bazel/output/execroot/org_tensorflow/bazel-out/k8-opt/bin/tensorflow
I linked the files using the below in my CMAKE:
file(GLOB LIBRARIES "${bazel_bin}/tensorflow/*.so.2")
message("LIBRARIES = ${LIBRARIES}")
After much research, trying to find out how to link libraries to gcc, going to /usr/bin and /usr/lib confirming the stuff are there. When I try to compile my keygen file, this is the error it blurts out.
$ gcc keygen.c -W -Wall /usr/bin/libgcrypt-config
/usr/bin/libgcrypt-config: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I've been told by numerous sources that I should compile this way to check if libgcrypt installed correctly.
$ gcc -o foo foo.c 'libgcrypt-config --cflags --libs'
But everytime I try to do that this is what it blurts out:
gcc: error: libgcrypt-config --cflags --libs: No such file or directory
I've confirmed that libgcrypt20 and libgcrypt20-dev are installed using dpkg --get-selections>installed. But I am just so utterly confused as to what may be wrong.
Any form of help would be much appreciated.
Try:
$ gcc -o foo foo.c `libgcrypt-config --cflags --libs`
` instead of '
I need to include libexplain to my project to do certain job. I install it and add the header libexplain/read.h to my code, so far so good and no error reported by the complier. But when I use the function explain_read() provided by libexplain and build the project it says:
/tmp/cc7NjAw0.o: In function `xl45_read(int, unsigned char*)':
connections.cpp:(.text+0x2f): undefined reference to `explain_read'
collect2: error: ld returned 1 exit status
and the build script is:
#!/bin/bash
echo > ./stdafx.h
g++ -O1 -Wall -o ./local_proxy (*.cpp...here is the source file list) -lz -lpthread -lpcap -L/usr/local/lib
actually when I type
whereis libexplain
in terminal, I get
libexplain: /usr/lib/libexplain.so /usr/lib/libexplain.a /usr/include/libexplain
I do a lot of searches and still have no idea what's going wrong. ):
You need to link your object files with libexplain. You can do it using the -l<library name>, like so:
g++ -O1 -Wall -o ./local_proxy *.cpp -lz -lpthread -lpcap -lexplain -L/usr/local/lib
Note the -lexplain flag. For a library with the a file name like libABC.so, you'd use -lABC to refer to that library. The documentation for link options with GCC can shed more light on it.
My program uses the GNU Multiple Precision Arithmetic Library to deal with numbers of an arbitrary size. I successfully compile it using GCC with:
gcc main.c -o diff -g -lgmp
However, when I try to use the MinGW crosscompiler compiler, I get the following error:
i686-w64-mingw32-gcc main.c -o diff.exe -g -lgmp
main.c:3:46: fatal error: gmp.h: No such file or directory
#include <gmp.h>//For files of arbitrary size
I then tried to tell it exactly where the header file was:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
Ok, so I figure now it successfully found the header, but cant find the library. So I tried again:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -L/usr/lib -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
I guess I need to specify the exact files to use, so I tried this:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g /usr/lib/libgmp.so
/usr/lib/libgmp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
So, I honestly don't know what to do and I'd really really appreciate your help.
First, a disclaimer: the cross-compiler you are using is neither distributed by, nor supported by MinGW.org, whom I represent; if you are looking for a pre-compiled solution, you should seek it from the distributor of the specific cross-compiler itself.
That said, I can offer the following insight, (which will apply, in general, to any cross-compiler): the headers you find in /usr/include, or in /usr/local/include, and the libgmp.so which you find in /usr/lib, or in /usr/local/lib, are intended for use with your native platform compiler. They are not suitable for, and cannot be used with your MinGW cross-compiler; attempting to do so will surely never work. Thus, you have two options:
Ask your cross-compiler distributor to provide a pre-compiled copy of gmp.dll, (or at the very least, a compatible import library, although you may need the gmp.dll to distribute with your own application anyway), and any associated header files, and/or equivalent statically linkable library, for use with your cross-compiler.
Use your cross-compiler to build gmp.dll yourself, then install it, its associated headers, and perhaps also its associated import library and/or equivalent statically linkable library, into the same prefix-path as the cross-compiler itself.