I compiled the object files, and then tried to compile the executable, which failed by saying that there are undefined references to functions in "theLib".
g++ -I./theLib/src -c -o obj/main.o src/main.cpp
(works so far)
g++ -L./theLib -Wl,-rpath=./theLib obj/main.o -ltheLib -o exe
(error: libtheLib.so: undefined reference to 'some_function')
I checked for answers everywhere, and they all just suggest moving the -ltheLib part after the dependencies (which I did). But it still doesn't work. What really boggles my mind is that the same library compiles just fine for an example in a different directory.
The library is in C. Can that mess up trying to compile C++? Or am I just missing something with compiling the .o files first?
Turns out the library depended on functions that I had to implement and provide in my own source code. I never knew that some libraries did that, but lesson learned. Once I implemented the functions that were causing the errors and added those source files, it worked.
Related
I have a project that I'm working on making run with CUDA. For various reasons, it needs to compile an executable either with or without GTK support, without recompiling all of the associated files. Under C, I accomplished this by compiling a base version of the objects to *.o and a GTK version of the objects to *.gtk.o. Thus, I can link to that library and if it needs to use GTK it will pull in those functions (and their requirements); if it doesn't it won't touch those objects.
Converting to nvcc has caused some issues: it works in either always or never GTK mode; but if I compile the libraries with the additional GTK objects, it refuses to ignore them and link a GTKless executable. (It fails with errors about being unable to find the cairo functions I call.)
I'm guessing that nvcc is linking to (at least one of) its helper functions embedded in the object, which is causing the linker to resolve the entire object.
Running ar d <lib> <objects.gtk.o> to manually strip them from the library will "fix" the problem, so there isn't a real dependency there.
I'm compiling/linking with
/usr/local/cuda/bin/nvcc --compiler-options -Wall --compiler-options -pipe
-rdc=true -O0 -g -G -I inc -I inc/ext -arch compute_20 -o program
program.cu obs/external.o libs/base.a libs/extra.a libs/core.a -lm
How can I get nvcc to ignore the unneeded objects?
How can I get nvcc to ignore the unneeded objects?
Before you can achieve that, you need to understand which symbol is causing the *.gtk.o objects to be pulled in from the library when they shouldn't be.
The way to do that is to run link with -Wl,--print-map, and look for linker messages such as:
Archive member included because of file (symbol)
libfoo.a(foo.o) main.o (foo)
Above, main.o referenced foo, which is defined in libfoo.a(foo.o), which caused foo.o to be pulled in into the main binary.
Once you know which symbols cause xxxx.gtk.o to be pulled into the link, searching the web and/or NVidia documentation may reveal a way to get rid of them.
I tried to run .c file called grover.c in this C application libquantum
www.libquantum.de/files/libquantum-1.1.1.tar.gz
Now I this application already contains a Makefile.in and I can generate the executables called shor and grover using the command
./configure
make
make demos
But when I try to run grover.c using gcc or clan like this
clang grover.c
It gives me error of lots of undefined function reference.
In function oracle':
grover.c:(.text+0x50): undefined reference toquantum_sigma_x'
grover.c:(.text+0x89): undefined reference to quantum_toffoli'
grover.c:(.text+0xc8): undefined reference toquantum_toffoli'
grover.c:(.text+0xf2): undefined reference to quantum_cnot'
grover.c:(.text+0x137): undefined reference toquantum_toffoli'
grover.c:(.text+0x16b): undefined reference to quantum_toffoli'
grover.c:(.text+0x1b0): undefined reference toquantum_sigma_x'
I need to know how can I remove this error and if I can run this c code called grover.c in this application.
Thanks,
It looks like your compiler can not find one or more libraries to link to. My hunch is that the makefile has the appropriate commands to invoke the linker.
If you look at your makefile, you probably will see some commands like -L -l,
when the flag -L add a directory to the default search path for libraries and the flag -l is used to name the library to link.
for example -L/lib/openGL -lglut32 would cause the library libglut32.so.X.Y.Z which is found in the directory /lib/openGL. (not this is for a Linux system, but it should be fairly similar for Mac).
N.B. X.Y.Z are the version number of the library.
Once you work this out, there may be issues with the load finding the libraries, especially if they are in non-standard locations.
------------------------ edit --------------------------
After I posted this, and went to bed I realized that I missed a potential case (and thanks to Paul Griffiths for also noticing my omission.....teach me to do multiple things at once).
Any how, just compiling a simple file, say hello.c, as clang hello.c -o hello works because everything is in one file and clang will automatically link to the C run-time library.
If, in your case the code is spread across multiple files, say grover.c and file1.c you would need to do:
clang -c grover.c -o grover.o
clang -c file1.c -o file1.o
clang grover.o file1.o -o grover
(or alteratively clang grover.c file1.c -o grover)
SO what the first two lines are doing is translating the source-code files (grover.c and file1.c) into object files. THe third line covers the two object files into an executable.
Finally, both these cases can be involved. You could have multiple files as well as missing libraries.
After battling my makefile woes I'm now onto problems with how the two libraries are supposed to interact. So, this is on Linux (CentOS 6.2 - 6.4, not that that seems to make much difference in terms of tools). The project, on the whole, is to be deployed in two flavors
A C++ Static library which is used for linking with other C++ appications (a *.a file)
A shared *.so which is deployed through python using Boost.python
I have everything compiling, but I'm not linking correctly somehow. In the case of the static library, it is built in two ways:
If meant to be linked with other C++ code, -fPIC is not used
If meant to be linked into the python module, use -fPIC
I control this through passing parameters to the make program. Presently, I'm trying to build the boost python module because the static stuff compiles just fine. So, I have dependencies on the boost libraries and zlib. The final linking command looks like this:
g++ -o pythonmod.so -L/boost/boost_libs -L/zlibs -lz -lboost_python -lboost_thread -lboost_regex -lboost_system /path/to/static.a -fPIC -shared [many_objects]
The "many_objects" comes from the various wrappers, and other code, that wraps the "pure" C++ from the boost.python layer in the code. Each of these object files are compiled with -fPIC as well. Their compiled with:
g++ -I/boost/boost_1_47 -I/usr/include/python2.6 -D _linux -MMD -std=c++0x -c -m32 -fPIC <input> -o <output>
The lines compiling the object files for the archive file look quite similar to the above only they do not include the python include directory.
I've found other links here to similar problems and tried the solutions but to no avail thus far. For example, this link uses -Wl,--whole-archive ... -Wl,--no-whole-archive. I tried this solution when I was trying to link in the static library archive before I was compiling it with -fPIC. Now that I'm doing that, I've tried this solution but also to no avail. In each case, every time I load up python and import the module, I get some sort of undefined symbol error --> something went wrong during linking.
How should I mix these libraries together to make the python module work?
After joining the gcc-help mailing list I received the pointer I needed to resolve the issue. The problem turned out to the ordering of the libraries used for linking on the build command line. Basically, the object files generated during the build for the *.so needed to be placed first. Then, the references to the boost and other libraries. Reordering the object files to reference the objects built for wrapping the static library before the other libraries was the key. No longer am I seeing weird "unresolved objects" when loading my python module.
After 4 or 5 years of using Visual Studio, my gcc knowledge had become sufficiently rusty that I'd forgotten the importance of ordering when it comes to linking.
I am trying to compile a program on my system with Debian Wheezy and g++4.7. I want it to be able to run on another system with Debian Squeeze (and no recent g++). I can't compile the program on the Squeeze, because I use certain C++11 features the old g++ does not support, as well as a new Boost version and libcrypto++9.
As far as I understand the usual way to get around this problem is to static link the libraries not supported at the other system, in my case libstdc, boost and crypto++.
My (linking) compiler call right now is
g++-4.7 .obj/btcmirco.o -Wl,-Bstatic -lboost_program_options -lboost_system -lcrypto++ -Wl,-Bdynamic -lcurl -static-libgcc -std=c++11 -o MyProgram
However I seem to have missed something, because it throws a lot of undefined reference errors. It works fine if I dynamic link to crypto++ (and only static link libstdc and boost).
Can anyone tell me whats wrong, or if there is a fundamental error in my approach?
The linker errors I get are (shorted):
`.text._ZN8CryptoPP22BufferedTransformationD2Ev' referenced in section `.text._ZN8CryptoPP22BufferedTransformationD1Ev[_ZN8CryptoPP22BufferedTransformationD1Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o): defined in discarded section `.text._ZN8CryptoPP22BufferedTransformationD2Ev[_ZN8CryptoPP22BufferedTransformationD5Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o)
`.text._ZN8CryptoPP25MessageAuthenticationCodeD2Ev' referenced in section `.text._ZN8CryptoPP25MessageAuthenticationCodeD1Ev[_ZN8CryptoPP25MessageAuthenticationCodeD1Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o): defined in discarded section `.text._ZN8CryptoPP25MessageAuthenticationCodeD2Ev[_ZN8CryptoPP25MessageAuthenticationCodeD5Ev]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libcrypto++.a(cryptlib.o)
I experienced the same problem and this has to do with the fact that you are trying to mix code generated by g++-4.7 (your program) with code generated by a previous version of g++ (cryptopp library).
The reason behind this is that when you execute compile the library executing make command, it uses the default version of g++ set up for your system, usually the one that comes with the OS.
In order to solve the issue what you should do is compile cryptopp library with g++-4.7.
For that, compile the library by executing make CXX=g++-4.7. The resulting static library shouldn't give you the error when being linked with your code.
I built a static library (.lib) with VS2012. I wrote a test program by including my header and then tried to link it with the .lib file with g++
g++ Test.cpp Gray.lib -o test.exe
(All files are in the same directory)
And I'm getting undefined reference to errors on functions in my library. What do I do? I already searched for many answers, those didn't help.
You cannot do that without resorting to hacks, because name mangling is different between compilers you want to use. The most straigforward way is to complile your library for g++ natively.