How do I solve these libcurl linking errors? - c++

[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 )

Related

Linker errors (library versions conflict)

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.

G++ error with -lxnt flag after xlnt is installed

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.

Why can't I link against shaderc?

I have a vulkan project that is trying to use shaderc.
The library was installed under the following path (linux system):
./libraries/shaderc/build/libshaderc
Doing ls in this directory gives:
CMakeFiles shaderc_combined_shaderc_test
cmake_install.cmake shaderc_c_smoke_test
CTestTestfile.cmake shaderc_shaderc_cpp_test
libshaderc.a shaderc_shaderc_private_test
libshaderc_combined.a shaderc_shaderc_test
libshaderc_shared.so shaderc_shared_shaderc_cpp_test
libshaderc_shared.so.1 shaderc_shared_shaderc_private_test
shaderc_combined.ar shaderc_shared_shaderc_test
shaderc_combined_shaderc_cpp_test
The documentation provided with the library explicitly states:
If the external project does not use CMake, then the external project can instead directly use the generated libraries.
shaderc/libshaderc/include should be added to the include path, and
build/libshaderc/libshaderc_combined.a should be linked. Note that
on some platforms -lpthread should also be specified.
I attempt to link the project as follows using make:
g++ -o "../build/VulkanEngine" obj/Debug/DebugCallback.o obj/Debug/Device.o obj/Debug/log.o obj/Debug/ImageViews.o obj/Debug/Instance.o obj/Debug/Pipeline.o obj/Debug/RenderPass.o obj/Debug/Surface.o obj/Debug/SwapChain.o obj/Debug/VkExtensionsStubs.o obj/Debug/GLFW_tools.o obj/Debug/main.o -L../libraries/glfw-3.2.1/bin -L../libraries/glm/bin/glm -L../libraries/vulkansdk-linux/1.1.97.0/x86_64/lib -L../libraries/shaderc/build/libshaderc -lstdc++fs -lglfw -lglm_static-lvulkan -llibshaderc_combined.a
In particular notice the argument -L../libraries/shaderc/build/libshaderc: and the argument -llibshaderc_combined.a
As you can see the specified linking path matches the installation path (libraries/ contains all the third party libraries my project uses).
However the linker complains:
/usr/bin/ld: cannot find -llibshaderc_combined.a
collect2: error: ld returned 1 exit status
make[1]: *** [VulkanEngine.make:119: ../build/VulkanEngine] Error 1
make: *** [Makefile:30: VulkanEngine] Error 2
So it seems I messed up the path somehow, but I don;t know how.
The -lname linkage option directs the linker to search in specified
(-Ldir) and default library search directories for either of the
files libname.so (shared library) or libname.a (static library). If it finds either of them them it searches
no more directories and inputs that file to the linkage. If it finds
both of them in the same search directory then it will prefer libname.so.
So change:
-llibshaderc_combined.a
to:
-lshaderc_combined
You must also be sure that -lshaderc_combined appears in the linkage
sequence before any other library that it depends on, and after any object file or library that depends upon it, or the linkage
is liable to fail with undefined reference errors.

Getting exe when building dll using libtool

I'm trying to compile .dll of this project on windows using MinGW. Everything goes ok except one point: output is the .exe file - not .dll.
Here is the notification, that libtool gave me:
*** 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.
Well, I've not found anywhere in project option -no-undefined and that's why I wonder what symbols(and how??) should be fixed to get needed .dll?
Maybe there are some issues with linker? I dont know where to change($LIBRARY_PATH = /c/mingw already) it and that's why during make this warning pops up:
*** 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: c:/Strawberry/c/bin/../lib/gcc/x86_64
-w64-mingw32/4.8.3/../../..//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.
Looks like your program need zlib, but c:/Strawberry/c/bin/../lib/gcc/x86_64
-w64-mingw32/4.8.3/../../..//libz.a is not valid (different target architecture - x86 vs x86_64?). You need to get a real zlib, compile for the same architecture and point your program to it.
you can use a .cmd file with following content
::source code file path
set src_path=source.cpp
::output file path
set bin_path=yourlib.dll
::library you need
set libs=-lmingw32 -lkernel32 -lshell32 -luser32 -lwsock32 -lws2_32 -lole32 -loleaut32
::windows subsystem
set sub_sys=-mwindows
::cpp version used by g++
set cpp_ver=-std=c++1y
::jump to g++ path
cd "%your_mingw32_folder_path%\bin\"
::run g++ with args
g++.exe "%src_path%" -o "%bin_path%" -Wall -W -w -static %sub_sys% %libs% %cpp_ver%
pause

Test for external undefined references in Linux

Is there a built in linux utility that I can use to test a newly compiled shared library for external undefined references? Gcc seems to be intelligent enough to check for undefined symbols in my own binary, but if the symbol is a reference to another library gcc does not check at link time. Instead I only get the message when I try to link to my new library from another program.
It seems a little silly to get undefined reference messages in a library when I am compiling a different project so I want to know if I can do a check on all references internal and external when I build the library not when I link to it.
Example error:
make -C UnitTests debug
make[1]: Entering directory `~/projects/Foo/UnitTests`
g++ [ tons of objects ] -L../libbar/bin -lbar -o UnitTests
libbar.so: undefined reference to `DoSomethingFromAnotherLibrary`
collect2: ld returned 1 exit status
make[1]: *** [~/projects/Foo/UnitTests] Error 1
Usually, undefined references are allowed when linking shared objects, but you can make the linker generate an error if there are undefined symbols in the object files that you are linking to create the shared library by supplying -z defs to the linker (or equivalently -Wl,-z,defs in the gcc command that calls the linker).