I am trying to compile my C++ project on Linux x64 with boost libraries 1.57.
This project is compiled with scons and I successfully compiled it on my Arch Linux, but this time failed on a Ubuntu machine.
I added -lboost_coroutine flag for linking but the error "undefined reference" still existed.
/usr/bin/g++ -o build/gcc.release/app -pthread -g
build/gcc.release/src/han/unity/rpcx.o
-lpthread -lz -lboost_coroutine -lboost_context -lboost_date_time
build/gcc.release/src/han/unity/rpcx.o: In function `attributes':
/usr/local/include/boost/coroutine/attributes.hpp:31: undefined reference
to `boost::coroutines::stack_traits::default_size()'
I noticed that the attributes.hpp is exactly one of the boost coroutine header files. And I tried with nm to boost coroutine libs and it seems no problem.
nm /usr/local/lib/libboost_coroutine.a | grep "default_size"
0000000000000170 T _ZN5boost10coroutines12stack_traits12default_sizeEv
I searched the possible reasons for this error and most are about the order of linker flags. And in this case the rpcx.o depends on boost_coroutine, so this appears in front.
What else could be the causes?
After several hours effort, I finally solved it.
That turns out to be the old boost (v1.55) lib still existing, which has static libraries with the same name of my manually installed boost library (v1.57). The linker found the v1.55 static libs before v1.57, so it used these libs for linking. However, in the old version, the function boost::coroutines::stack_traits::default_size() is still not introduced, which makes the linker cannot find the right location of this function, and returns "undefind reference".
For those who happens to find this questions from googling "undefined reference" errors during compiling, I got several steps about debugging this kind of problem and wrote here for your information.
Check if the library you linked with exists in /usr/lib/ or /usr/local/lib/, if not, try to install these first.
Check if you added the correct linking flag for your referred libs. For example, if you use boost_coroutine libs, be sure to add -lboost_coroutine during linking.
Check if the order of linking flags are correct (for gcc). This could be the cause of most cases. Make sure to put B in front of A if B depends on A.
Check if different versions exists for the same libraries.
I hope these could help somehow.
Related
I am trying to cross-compile apache-qpid for an arm system from a debian.
There is undefined reference to __dlopen error, but it seems that it is related to the previous warning:
using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ...
Here is the detail:
[ 86%] Linking CXX shared library libqpidcommon.so
CMakeFiles/qpidcommon.dir/qpid/sys/posix/Shlib.cpp.o: In function
`qpid::sys::Shlib::load(char const*)':
/home/mert/qpid-cpp-0.34/src/qpid/sys/posix/Shlib.cpp:32: warning: Using
'dlopen' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
/home/mert/IDE/cVEND/00.00.14/bin/../arm-feig-linux-
gnueabi/sysroot/usr/lib/libdl.a(dlopen.o): In function `dlopen':
dlopen.c:(.text+0xc): undefined reference to `__dlopen'
I do not know what is happening exactly and how to solve it.
Here there is a similiar thing, I tried to add -static -ldl -lc C_FLAGS but made no difference.
Any help appreciated.
EDIT :
EDIT :
I am not sure exactly what is solved the problem, but I think that -ldl was looking exactly for libdl.so, but in arm directory, it was libdl-2.19.so, thus, probably it was then looking for and finding in another directory. I have linked libdl.so to libdl-2.19.so and now it is compiling.
The linker needs the options, not the compiler. See LDFLAGS.
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
Extra flags to give to compilers when they are supposed to invoke the
linker, ‘ld’, such as -L. Libraries (-lfoo) should be added to the
LDLIBS variable instead.
If this error occurs during the make step try doing
make LIBS=-ldl
And make sure the library path is present in LDFLAGS
export LDFLAGS=-L<path/to/ldl>
I've looked through the other similar questions about this topic, and I think there's something OSX-specific I'm missing.
I'm trying to statically link Basho's fork of LevelDB to my C application (since packaged versions of LevelDB will use Google's mainline). Even using the c++ linker and adding -lc++ to the command line, I still get flooded with errors about missing c++ STL symbols such as:
"std::string::_Rep::_M_destroy(std::allocator const&)",
referenced from:
_leveldb_open in libleveldb.a(c.o)
The strange thing is, I know I have the C++ bits enabled right because I'm also linking to libsnappy, and before I added the link directive there was unresolved libsnappy symbols (obviously) that are now cleared up.
As far as I know, I have the latest version of xcode & the rest of the compiler chain. libleveldb is also compiled using the same toolchain as my regular application. Here's the command line I'm trying:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-g -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/get_rid_status.dir/get_rid_status.c.o
-o get_rid_status
/usr/local/lib/libdb.a /usr/lib/libssl.dylib /usr/lib/libcrypto.dylib
/usr/lib/libaprutil-1.dylib /usr/lib/libapr-1.dylib -lpthread -ldl -lm
-lz leveldb/libleveldb.a /usr/local/lib/libsnappy.dylib -lc++
I'm linking with the c++ linker and adding the c++ standard library with -lc++ to no avail.
UPDATE
Found the correct answer, which can be found below. Kudos to the users who told me the right etiquette when I originally answered my own question here.
Turns out, leveldb adds some extra linker flags I didn't notice at first. The culprit is -mmacosx-version-min=10.8. Adding that flag to the link step of my C application got everything to line up.
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 have a problem, i want to compile my application with static linking of mysql connector.
My command line:
g++ -o newserver stdafx.cpp ... -lboost_system -lboost_thread
-lpthread -lmysqlcppconn -static /usr/lib/libmysqlcppconn-static.a -std=c++0x
But i have error:
/usr/bin/ld: cannot find -lmysqlcppconn
/tmp/ccxpOfdZ.o: In function `IsEqualsDns(unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)':
Server.cpp:(.text+0x356e): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: ld returned 1 exit status
How can i fix this?
Thanks!
Where is the library libsqlcppconn.a or libsqucppconn.so
(static or dynamic)? The compiler is looking for it, and
doesn't find it.
Presumably, this is the same library as
/usr/lib/mysqlcppconn-static.a. If so, just drop the
-lmysqlcppconn. Or just use -lmysqlcppconn-static (no
spaces), and forget about the /usr/lib/libmysqlconn-static.a.
With a name like that, there shouldn't be a corresponding .so,
which means that g++ will link it statically, even without the
-static. You only need the -static if there is both
a libmysqlconn-static.so and a libmysqlconn-static.a in the
same directory.
With regards to the second error (which is just a warning, but
will cause problems if you try to run the linked program on
other machines, or even after an upgrade of your machine): if
you use -static anywhere in your command line (as you
currently do), then it applies to all files linked afterwards.
Including the system libraries, which you don't want to link
statically. My guess is that the -static isn't necessary (see
above); if it is, place it immediately before the library you
want to link statically, and place a -dynamic immediately
after (so that any following libraries, including the system
libraries, will be dynamically linked).
You could try g++ -static YOUR ARGUMENTS.
If you are coming from a Windows platform, linking against Boost can give a few surprises. The typicall Boost installation (e.g. after ./b2 install) will make both dynamic and static libraries and put them in the same directory. Typically, the two library forms only differ in their extension (.so or .a).
Windows supports auto-linking, which basically means that library files contain some flags in their first few bytes indicating whether they are for dynamic or for static linking. On Linux platforms, this is not the case and the linker gets confused which file to load (since you don't provide the extension of the library name). Therefore, you need to tell your linker which form of linking you want.
So I'm going nuts trying to figure this one out. Here's my basic setup:
I'm compiling a shared library with a bunch of core functionality that uses a lot of boost stuff. We'll call this library libpf_core.so. It's linked with the boost static libraries, specifically the python, system, filesystem, thread, and program_options libraries. This all goes swimmingly.
Now, I have a little test program called test_socketio which is compiled into a shared library (it's loaded as a plugin at runtime). It uses some boost stuff like boost::bind and boost::thread, and it's linked again libpf_core.so (which has the boost libraries included remember).
When I go to compile test_socketio though, out of all my plugins it gives me a linking error:
[ Building test_socketio ]
g++ -c -pg -g -O0 -I/usr/local/include -I../include test_socketio.cc -o test_socketio.o
g++ -shared test_socketio.o -lpy_core -o test_socketio.so
Undefined symbols:
"boost::lock_error::lock_error()", referenced from:
boost::unique_lock<boost::mutex>::lock() in test_socketio.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
And I'm going crazy trying to figure out why this is. I've tried explicitly linking boost::thread into the plugin to no avail, tried ensuring that I'm using the boost headers associated with the libraries linked into libpf_core.so in case there was a conflict there.
Is there something OSX specific regarding boost that I'm missing? In my searching on google I've seen a number of other people get this error but no one seems to have come up with a satisfactory solution.
Edit: Figured it out, OSX comes with boost 1.40 in /usr/local/include. Needed to put the headers for my version of boost somewhere and make sure that my plugins sees those first.
You need to link to libboost_thread. Add the -lboost_thread switch.
When you link libpf_core.so against the static boost libraries, it's only going to get copies of the functions it actually uses. The linker doesn't bother to pull in functions that aren't referenced by the code in your library.
You need to link your test program against the boost libraries as well. You can't reliably "chain" the linkages.