I am developing an application in Linux, which requires static library of curl.Only http and https support is required.I have tried many ways like -Wl,-Bstatic -libcurl , linking to libcurl.a etc. Most alarming is that, I haven't seen anybody who has been successful in doing so, in linux.Only thing I found was in Windows,
Linking project with statically build curl
But in linux , almost all answers are like following.
Static linking libcurl using c.
Is it so? Whether it is impossible to make standalone library of curl in linux ?
Following are my build options and results
-Wl,-Bstatic -pthread -lcrypto -Wl,-Bdynamic -ldl -lcurl
No error !!!!!
-Wl,-Bstatic -pthread -lcrypto -ldl -lcurl
errors ... cannot find -lgcc_s
-static -pthread -lcrypto -ldl -lcurl
lot of errors starting with undefined reference "idn_free"
4.-static -pthread -lcrypto -ldl -ldn -lcurl
no change.... lot of errors starting with undefined reference "idn_free"
-static /usr/lib/i386-linux-gnu/libpthread.a /usr/lib/i386-linux-gnu/libcrypto.a /usr/lib/i386-linux-gnu/libdl.a /usr/lib/i386-linux-gnu/libidn.a /usr/lib/i386-linux-gnu/libcurl.a
no change.... lot of errors starting with undefined reference "idn_free"
Related
I've installed ffmpeg using vcpkg install ffmpeg
When I include the dependency in my cmake project, like so:
find_path(AVCODEC_INCLUDE_DIR libavcodec/avcodec.h)
find_library(AVCODEC_LIBRARY avcodec)
find_path(AVFORMAT_INCLUDE_DIR libavformat/avformat.h)
find_library(AVFORMAT_LIBRARY avformat)
find_path(AVUTIL_INCLUDE_DIR libavutil/avutil.h)
find_library(AVUTIL_LIBRARY avutil)
find_path(AVDEVICE_INCLUDE_DIR libavdevice/avdevice.h)
find_library(AVDEVICE_LIBRARY avdevice)
target_link_libraries(${TARGET_NAME} PRIVATE
${AVCODEC_LIBRARY} ${AVFORMAT_LIBRARY} ${AVUTIL_LIBRARY} ${AVDEVICE_LIBRARY}
)
My windows build works fine, however, on linux, I get the error:
[29/29] Linking CXX shared library libjni.so
2021-11-14T12:38:02.510164800Z FAILED: libjni.so
2021-11-14T12:38:02.510171600Z : && /usr/bin/g++-11 -fPIC -O3 -DNDEBUG -shared -Wl,-soname,libjni.so -o libjni.so CMakeFiles/jni.dir/src/jni.cpp.o CMakeFiles/jni.dir/src/core/audio.cpp.o CMakeFiles/jni.dir/src/core/files.cpp.o CMakeFiles/jni.dir/src/core/fs/file_utils.cpp.o CMakeFiles/jni.dir/src/core/spectrogram.cpp.o CMakeFiles/jni.dir/src/core/utils.cpp.o -L/usr/lib/gcc/x86_64-linux-gnu/10 -Wl,-rpath,/root/build/Release/_deps/fmt-build /root/vcpkg/installed/x64-linux/lib/libfftw3f.a _deps/fmt-build/libfmt.so.8.0.1 _deps/xxhash-build/libxxhash.a /root/vcpkg/installed/x64-linux/lib/libavcodec.a /root/vcpkg/installed/x64-linux/lib/libavformat.a /root/vcpkg/installed/x64-linux/lib/libavutil.a /root/vcpkg/installed/x64-linux/lib/libavdevice.a _deps/kistream_proto_cpp-build/libgenerated_srcs.a -lm -Wl,--as-needed /root/vcpkg/installed/x64-linux/lib/libprotobuf.a -lpthread && :
2021-11-14T12:38:02.510185200Z /usr/bin/ld: /root/vcpkg/installed/x64-linux/lib/libavcodec.a(h264_intrapred_10bit.o): warning: relocation against `ff_pw_512' in read-only section `.text'
2021-11-14T12:38:02.510187600Z /usr/bin/ld: /root/vcpkg/installed/x64-linux/lib/libavcodec.a(vc1dsp_mmx.o): relocation R_X86_64_PC32 against symbol `ff_pw_9' can not be used when making a shared object; recompile with -fPIC
I think, your issue is related to Position Independent Code. It can be resolved if you compile by giving -fPIC option in vcpkg.
You can look at this github issue of vcpkg repo. They gave an example that how can add compiler option to vcpkg`s port CMake file.
I did not get response from Qualcomm forum so I decided to post here. When I was trying to run examples of Halide for Hexagon by running make run as written in the document. Then I got the following issue. The -lc++abi is missing.
clang++ -std=c++11 -I /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/include -stdlib=libc++ -O3 -g -fno-rtti -rdynamic conv3x3_generator.cpp /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/lib/libHalide.a /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/tools/GenGen.cpp -o /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/Examples/build/offload/hexagon_benchmarks/bin/conv3x3.generator -lz -lrt -ldl -lpthread -lm
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked the /usr/lib and find. So it should be there?
./x86_64-linux-gnu/libc++abi.so.1.0
./x86_64-linux-gnu/libc++abi.so.1
./llvm-10/lib/libc++abi.so.1.0
./llvm-10/lib/libc++abi.so.1
Did I miss anything or make anything stupid? Thanks!
ld is your system's host linker -- that's GNU BFD ld. clang++ must be in your PATH but it's the host clang++ and not the hexagon-clang++ that would be with Halide/Hexagon tools.
I contacted the person from Qualcomm. I am not supposed to use either /usr/bin/clang++ nor hexagon-clang++. I downloaded clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz from https://releases.llvm.org/7.0.1/. You should use clang++ under the bin folder after you extract it. Now it works for me.
I'm writing a dynamic library that's loaded at runtime as a plugin. At runtime, the library fails to load with the following message:
dlerror:/path/to/so: undefined symbol: fstat
The dynamic library consists of a bunch of static libraries linked together, including libsodium. I've tracked down libsodium as the only place that fstat() is used in the library.
As I understand it, fstat() should be part of libc, and should not require additional libraries to be installed. What am I missing?
EDIT1:
I've found some additional information about how linking to fstat() is different than most functions, but I'm not sure exactly how it applies to my situation. I am compiling/linking libsodium with the provided makefiles for their distribution, and the dynamic library is being compiled with the compiler driver as recommended in that answer.
EDIT2: here's the linker command, generated by CMake:
/usr/bin/c++ -fPIC -O3 -DNDEBUG -rdynamic -nodefaultlibs -undefined_warning -fPIC -fvisibility=hidden -shared -Wl,-soname,lin.xpl -o src/xplane_plugin/lin.xpl src/path/to/object/file1.cpp.o src/path/to/object/file2.cpp.o src/plugin/libplugin.a /usr/local/lib/libpng16.a -lz src/plenty/of/dependencies.a lib/glew/libglew.a src/another/library.a /usr/local/lib/libsodium.a /usr/lib/x86_64-linux-gnu/libcurl.so lib/json11/libjson11.a -lpthread deps/some/library.a /usr/local/lib/libzip.a -lbz2 -llzma -lssl -lcrypto -lstdc++fs -lz
So i am trying to compile a simple GLFW window app, and i ran into a linker problem.
gcc -o bin/mtx_gui `pkg-config --libs glfw3 glew` src/main.c
i use this command to compile single main. pkg-config expands into -L/usr/local/lib -lglfw3 -lGLEW -lGLU -lGL which should compile everything. i checked all libs are where they suposed to be. no idea why it is not linking it
main.c:(.text.startup+0x2): undefined reference to `glfwInit'
First, as pointed by G.M in the comment, main.c goes before all libs. second and the most important.
-lglfw3 -lrt -lm -ldl -lpthread -lGL
Libpthread must be also linked, and if you plan on using opengl link Libgl as shown above.
I'm trying to load a library to Firefox, and I get the following error in the terminal:
http://pastebin.com/ZLryd20D,
gcc -Wall -fPIC -c 11.cpp ,
gcc -shared -o libshared.so 11.o -ldl ,
LD_PRELOAD=$PWD/libshared.so firefox ,
/bin/sh: symbol lookup error: /home/enigma/Desktop/compilacionproceso/libshared.so: undefined symbol: __gxx_personality_v0
gcc -shared -o libshared.so 11.o -ldl -lstdc++
That's the wrong solution, that happens to work on Linux by accident.
The correct command line to build your shared library is:
g++ -shared -o libshared.so 11.o
(contrary to popular belief, gcc and g++ are not the same thing).
Answer from the OP himself, taken from a revision of the question:
I solved the problem adding a flag -lstdc++ for create the library
thanks to this post
What is __gxx_personality_v0 for?
cd /directory
gcc -Wall -fPIC -c 11.cpp
gcc -shared -o libshared.so 11.o -ldl -lstdc++
LD_PRELOAD=$PWD/libshared.so program