I have a cmake project which uses conan as its package manager. The project uses boost components of version 1.71 and i have installed libboost-dev (v 1.62) which cannot be deleted from my system.
/usr/bin/ld: warning: libboost_system.so.1.62.0, needed by /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/libboost_filesystem.so, may conflict with libboost_system.so.1.71.0
/usr/bin/ld: warning: libboost_filesystem.so.1.71.0, needed by bin/libAppUtil.so, may conflict with libboost_filesystem.so.1.62.0
/usr/bin/ld: warning: libboost_filesystem.so.1.71.0, needed by bin/libAppUtil.so, may conflict with libboost_filesystem.so.1.62.0
bin/libCoreInt.so: undefined reference to `boost::filesystem::native(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I don't know if the conflict is a source of linker errors but i guess it is
There are 2 versions of shared library:
libboost_system.so.1.62.0 (already existing )
libboost_system.so.1.71.0 (project requirement)
Since the shared library (libboost_system.so.1.62.0) cannot be deleted. Please upgrade the existing library to libboost_system.so.1.71.0. The issue should be resolved.
But again since there is dependency on libboost_system.so.1.62.0, we
could do the following:
Project specific cmake file should make a reference to directory having the shared library 'libboost_system.so.1.71.0 '.
So when the project is build the executable should point to the version : libboost_system.so.1.71.0.
Related
I've been trying to compile an open-source C++ project Typesense, which has this list of dependencies:
Snappy
zlib
OpenSSL (>=1.0.2)
curl
ICU
brpc
braft
Host and target OS is Debian Linux. Compilation is handled via cmake->make sequence of commands. I was able to install some of dependencies through a package manager (I believe they reside in /usr/lib then), the last two I had to compile on my own, I put them in /usr/local/lib.
All the dependencies were successfully compiled, and the target project compiled too.
When it comes to linking stage, I get numerous errors like
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcurl.a(libcurl_la-easy.o): in function `global_init':
(.text+0x94): undefined reference to `libssh2_init'
...
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcurl.a(libcurl_la-http2.o): in function `on_header':
(.text+0x6c): undefined reference to `nghttp2_session_get_stream_user_data'
...
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcurl.a(libcurl_la-socks_gssapi.o): in function `check_gss_err.part.0':
(.text+0x57): undefined reference to `gss_release_buffer'
/usr/bin/ld: (.text+0x77): undefined reference to `gss_display_status'
/usr/bin/ld: (.text+0x9b): undefined reference to `gss_release_buffer'
/usr/bin/ld: (.text+0xcf): undefined reference to `gss_release_buffer'
/usr/bin/ld: (.text+0xef): undefined reference to `gss_display_status'
/usr/bin/ld: (.text+0x112): undefined reference to `gss_release_buffer'
/usr/bin/ld: (.text+0x17e): undefined reference to `gss_release_buffer'
...
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcurl.a(libcurl_la-curl_rtmp.o): in function `rtmp_connect':
(.text+0xd4): undefined reference to `RTMP_Connect1'
...
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcurl.a(libcurl_la-openldap.o): in function `ldap_connecting':
(.text+0x111): undefined reference to `ldap_result'
There is at least a hundred of such errors. I'm not at all proficient with Linux and complex building of projects. How do I possibly fix linking errors for libraries that I just downloaded through a package manager?
EDIT: Libraries, that cmake seems to link against at the end:
braft;
brpc;
/usr/lib/x86_64-linux-gnu/libleveldb.a;
glog;
h2o-evloop;
iconv;
/usr/lib/x86_64-linux-gnu/libcurl.a;
for;
/usr/lib/x86_64-linux-gnu/libicui18n.a;
/usr/lib/x86_64-linux-gnu/libicuuc.a;
/usr/lib/x86_64-linux-gnu/libicudata.a;
rocksdb;
/usr/lib/x86_64-linux-gnu/libsnappy.a;
/usr/lib/x86_64-linux-gnu/libz.a;
rt;
/usr/lib/x86_64-linux-gnu/libssl.a;
/usr/lib/x86_64-linux-gnu/libcrypto.a;
pthread;
dl;
-static-libgcc;
-static-libstdc++;
gflags_shared;
/usr/lib/x86_64-linux-gnu/libprotobuf.a;
-lpthread
Your dependency list is incomplete. It only includes immediate dependencies.
Your version of libcurl is built with ssh, gssapi, nghttp2, ldap, rtmp and possibly other goodies, none of which you are linking against. You are using static linking, and static libraries do not have a built in concept of dependencies. This means you have to manually include all the non-immediate dependencies in your build command. You can get the impression of how many more libraries you need to include by executing this command
ldd /path/to/your/libcurl.so
and observing the list of dependencies your libcurl has.
The same thing may be true about other libraries you use.
One way to resolve the issue is to use dynamic linking. This way you just link to immediate dependencies, and they know their dependencies.
I am trying to install the xlnt library on Ubuntu 18. I have installed xlnt exactly as the instructions say on the repo. When I try to compile my code, the following error pops up:
/usr/bin/ld: cannot find -lxlnt
collect2: error: ld returned 1 exit status
makefile:204: recipe for target 'BOF-debug-static' failed
make: *** [BOF-debug-static] Error 1
I have been installing other libraries to get the code working, and I've noticed that the other libraries are creating .a files at /usr/local/lib along with a few other .la, and .so files. When I install xlnt, it is not creating any .a files, but does create a .so and .so.1.2 files. Not sure if that is relevant, but it's something I've noticed.
How do I make xlnt discoverable to g++ and get the -lxlnt flag to work?
The target you are building BOF-debug-static is evidently one that requests
either a fully static linkage, with the -static linkage option, or possibly one that
requests static linkage specifically of libxlnt, with a linkage option such as:
-Wl,-Bstatic -lxlnt -Wl,-Bdynamic
Since, as you observed, libxlnt by default provides only a shared/dynamic library libzlint.so ( -> libzlint.so.X.Y.Z),
and no static library libzlnt.a, the linker ignores the the shared library when
required to link -lxlnt statically and says:
/usr/bin/ld: cannot find -lxlnt
You cannot link a shared library statically.
However, if you configure the CMake build system with:
cmake -DSTATIC=ON [your previous options...]
then make will build a static library and running make install (as root) will create /usr/local/lib/libxlnt.a.
I've been developing with CentOS, Qt 4.7, and GCC 4.4
I've just installed Red Hat Developer Toolset 1.1 which includes GCC 4.7.2, and at the end of make, I get an error
/usr/bin/ld: ../../bin/Solo: undefined reference to symbol 'pthread_rwlock_trywrlock##GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_rwlock_trywrlock##GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
I'm guessing that Qt threads is referencing to that. How can I fix it?
You want to compile with -pthread which does more than just link with libpthread:
Adds support for multithreading with the pthreads library. This
option sets flags for both the preprocessor and linker.
You just need to add CONFIG += thread to your .pro file.
Read the note: try to add /lib64/libpthread.so.0 into Makefile (-lpthread after gcc command, or /lib64/libpthread.so.0 after ld (or after gcc -shared)), or something like LIB += -lpthread if there's such definition somewhere.
See also: Adding external library into Qt Creator project and http://www.qtcentre.org/threads/39144-How-to-add-a-lib-to-a-qt-project
Btw, post your Makefile, so somebody will be able to point to exact line.
In my little laptop Linux (where I have a mixed bag of libraries),
I just had to add
LDFLAGS=-lpthread
AT THE END of the configure command arguments.
After that, make did its job perfectly (With the existing libraries).
I received similar 'Linker error: undefined reference to symbol' errors attempting to compile and install Python-3.7.2 on FreeBSD 12.
/usr/bin/ld: error: undefined symbol: _Py_GetGlobalVariablesAsDict
/usr/bin/ld: error: undefined symbol: _PyCoreConfig_AsDict
/usr/bin/ld: error: undefined symbol: _PyMainInterpreterConfig_AsDict
Resolved by passing LDFLAGS=-lpthread directly to make of lang/python37 or by adding to /etc/make.conf.
If using portmaster to install/update use -m to pass the arguement to make e.g.portmaster -a -m 'LDFLAGS=-lpthread'
I am trying to compile my gcc code using the following make command .
OS :Redhat ,gcc - 4.1
But I am getting error as follows :
rmtrain#lintrni130 $ /usr/local/bin/make all
[ 21%] Built target GCVCore
Linking CXX executable CFE
/usr/bin/ld: warning: libicui18n.so.36, needed by ../../Generic/icu/lib/libicuio.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libxalanMsg.so.110, needed by ../../Generic/Xalan/lib/libxalan-c.so, not found (try using -rpath or -rpath-link)
CMakeFiles/CFE.dir/trnuser1/rmtrain/DevelopmentEnv/Generic/ConvUI/GCVConvUISetting.o: In function `xercesc_2_6::XMLAttDefList::~XMLAttDefList()':
GCVConvUISetting.cpp:(.text._ZN11xercesc_2_613XMLAttDefListD0Ev[xercesc_2_6::XMLAttDefList::~XMLAttDefList()]+0x2f): undefined reference to `xercesc_2_6::XMemory::operator delete(void*)'
Please Help with this .
The warnings means that some libraries you link to have dependencies on other shared libraries, and those libraries weren't found in the linker's search path. The linker manual describes how it forms that search path in the docs for the -rpath-link option
They're only warnings, so haven't caused your link to fail. It will be a problem if those required libs aren't found at run-time, but is not necessarily a problem at link-time.
If you want to silence the warnings you will need to find out which directory contains libicui18n.so.36 and libxalanMsg.so.110 and use one of the methods described in the manual to tell the linker to look in that directory.
The last line is the real problem, and indicates you are not linking to the library which defines that symbol. You'll need to find out which library it is and link to it with -lfoo, it will probably be something like -lxerces
i reinstalled icu 3.2 instead of 3.6.It worked fine then.
[Administrator#windows ~]$ g++ client.cpp -lcurl -o client.exe
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0x23): undefined reference to `_imp__curl_global_init'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0x5f): undefined reference to `_imp__curl_formadd'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0x9b): undefined reference to `_imp__curl_formadd'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0xa2): undefined reference to `_imp__curl_easy_init'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0xc8): undefined reference to `_imp__curl_easy_setopt'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0xe4): undefined reference to `_imp__curl_easy_setopt'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0xf1): undefined reference to `_imp__curl_easy_perform'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0x101): undefined reference to `_imp__curl_easy_cleanup'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0x10e): undefined reference to `_imp__curl_formfree'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccKXFUtC.o:client.cpp:(.text+0x11b): undefined reference to `_imp__curl_slist_free_all'
collect2: ld returned 1 exit status
I don't have this problem on linux so I don't know why this happens on windows. I googled it already and didn't find anything except mailing list archives with the same question and reply saying "google it".
I'm using mingw. I did get some linker warnings when I built libcurl but they seemed to be ssl related and I don't know if it's a big deal because it built without errors.
*** Warning: linker path does not have real file for library -lssl.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libssl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /ssl/lib/libssl.a
*** Warning: linker path does not have real file for library -lcrypto.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libcrypto and none of the candidates passed a file format test
*** using a file magic. Last file checked: /ssl/lib/libcrypto.a
*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib//libz.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
I was able to avoid these curl linking errors on windows (mingw win32) by adding option -lcurl.dll. -DCURL_STATICLIB was not needed in my case.
My build has two libcurl files in mingw/lib folder: libcurl.a and libcurl.dll.a
Libtool only built a static libcurl and not a dynamic library. Your headers are looking for a dynamic libcurl. It's probably not libcurl's fault, because I can see code in the headers that supports __declspec(dllimport) and __declspec(dllexport) (that's a good sign the package author knows what's what.
Technical details: see this answer regarding libssh.
Solution: Compile with -DCURL_STATICLIB.
Was having the same issue using netbeans 7.1 with mingw. From properties, linker adding library libcurl.dll.a solved the issue for me.
This file was located under curl-7.28.1\lib.libs after I ran the mingw make.
I had similar error (with libz and libsqlite) in different projects.
It is produced by GNU libtool script.
The reason in my case was lack of some files for these libraries (.la ?) or maybe libz.dll.a variants of the libraries.
To have all necessary files for automake/autoconf build ./configure --prefix=... ; make, you'll have to build zlib, crypto and ssl with configure and make to under the same MSYS.
cmake or custom makefile builds will usually not work as dependencies for shared-library autotool build.
Another and the most simple option is to build dynamic curl with cmake ( https://github.com/bagder/curl.git )