libpthread so 0 error adding symbols DSO missing from command line

Question

When I m compiling openvswitch-1 5 0  I ve encountered the following compile error    gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith      -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init  -g -O2 -export-dynamic    -lpthread     -o utilities ovs-dpctl utilities ovs-dpctl o lib libopenvswitch a   home jyyoo src dpdk build lib librte eal a   home jyyoo src dpdk build lib libethdev a   home jyyoo src dpdk build lib librte cmdline a   home jyyoo src dpdk build lib librte hash a   home jyyoo src dpdk build lib librte lpm a   home jyyoo src dpdk build lib librte mbuf a   home jyyoo src dpdk build lib librte ring a   home jyyoo src dpdk build lib librte mempool a   home jyyoo src dpdk build lib librte malloc a -lrt -lm        usr bin ld   home jyyoo src dpdk build lib librte eal a eal o   undefined reference      to symbol  pthread create  GLIBC 2 2 5        lib x86 64-linux-gnu libpthread so 0  error adding symbols  DSO missing from       command line   If I try to see the symbols of libpthread  it looks fine     readelf -s  lib x86 64-linux-gnu libpthread so 0   grep pthread create    199  0000000000008220  2814 FUNC    GLOBAL DEFAULT   13 pthread create  GLIBC 2 2 5    173  0000000000008220  2814 FUNC    LOCAL  DEFAULT   13   pthread create 2 1    462  0000000000008220  2814 FUNC    GLOBAL DEFAULT   13 pthread create  GLIBC 2 2   Could you give any hints or pointers

User · Answer

I also encountered same problem  I do not know why  i just add -lpthread option to compiler and everything ok   Old     g   -rdynamic -m64 -fPIE -pie  -o  tmp node out Release mksnapshot      o   a -ldl -lrt   got following error  If i append -lpthread option to above command then OK    usr bin ld   tmp node out Release obj host v8 libbase deps v8 src base platform condition-variable o  undefined reference to symbol  pthread condattr setclock  GLIBC 2 3 3    lib x86 64-linux-gnu libpthread so 0  error adding symbols  DSO missing from command line collect2  error  ld returned 1 exit status

User · Answer

I found another case and therefore I thing you are all wrong   This is what I had    usr lib64 gcc x86 64-suse-linux 4 8             x86 64-suse-linux bin ld  eggtrayicon o  undefined reference to symbol  XFlush   usr lib64 libX11 so 6  error adding symbols  DSO missing from command line   The problem is that the command line DID NOT contain -lX11 - although the libX11 so should be added as a dependency because there were also GTK and GNOME libraries in the arguments   So  the only explanation for me is that this message might have been intended to help you  but it didn t do it properly  This was probably simple  the library that provides the symbol was not added to the command line   Please note three important rules concerning linkage in POSIX    Dynamic libraries have defined dependencies  so only libraries from the top-dependency should be supplied in whatever order  although after the static libraries  Static libraries have just undefined symbols - it s up to you to know their dependencies and supply all of them in the command line The order in static libraries is always  requester first  provider follows  Otherwise you ll get undefined symbol message  just like when you forgot to add the library to the command line When you specify the library with -l lt name gt   you never know whether it will take lib lt name gt  so or lib lt name gt  a  The dynamic library is preferred  if found  and static libraries only can be enforced by compiler option - that s all  And whether you have any problems as above  it depends on whether you had static or dynamic libraries Well  sometimes the dependencies may be lacking in dynamic libraries  D

User · Answer

I found I had the same error  I was compiling a code with both lapack and blas  When I switched the order that the two libraries were called the error went away     LAPACK LIB   -llapack -lblas  worked where  LAPACK LIB   -lblas -llapack  gave the error described above

User · Answer

The same problem happened to me when I use distcc to make my c   project  Finally I solved it with export CXX  distcc g

User · Answer

Background  The DSO missing from command line message will be displayed when the linker does not find the required symbol with it s normal search but the symbol is available in one of the dependencies of a directly specified dynamic library   In the past the linker considered symbols in dependencies of specified languages to be available  But that changed in some later version and now the linker enforces a more strict view of what is available  The message thus is intended to help with that transition   What to do   If you are the maintainer of the software  You should solve this problem by making sure that all libraries that are needed to satisfy the needed symbols are directly specified on the linker command line  Also keep in mind that order often matters    If you are just trying to compile the software  As a workaround it s possible to switch back to the more permissive view of what symbols are available by using the option -Wl --copy-dt-needed-entries   Common ways to inject this into a build are to export LDFLAGS before running configure or similar like this   export LDFLAGS  -Wl --copy-dt-needed-entries    Sometimes passing LDFLAGS  -Wl --copy-dt-needed-entries  directly to make might also work

User · Answer

The error message depends on distribution   compiler version   Ubuntu Saucy    usr bin ld   mnt root ffmpeg-2 1 1  libavformat libavformat a http o   undefined reference to symbol  inflateInit2    lib x86 64-linux-gnu libz so 1  error adding symbols  DSO missing from command line   Ubuntu Raring   more informative    usr bin ld  note   uncompress  is defined in DSO  lib x86 64-linux-gnu libz so 1 so try adding it to the linker command line   Solution  You may be missing a library in your compilation steps  during the linking stage  In my case  I added  -lz  to makefile   GCC flags   Background  DSO is a dynamic shared object or a shared library

User · Answer

The same thing happened to me as I was installing the HPCC benchmark  includes HPL and a few other benchmarks   I added -lm to the compiler flags in my build script and then it successfully compiled

User · Answer

What I have found is that sometimes the library that the linker complains about is not the one causing the problem  Possibly there is a clever way to work out where the problem is but this is what I do    Comment out all the linked libraries in the link command  Clean out all  o s   so s etc  Usually make clean is enough  but you may want to run a recursive find   rm  or something similar   Uncomment the libraries in the link command one at a time and re-arrange the order as necessary     peter karasev  I have come across the same problem with a gcc 4 8 2 cmake project on CentOS7  The order of the libraries in  target link libraries  section is important  I guess cmake just passes the list on to the linker as-is  i e  it doesn t try and work out the correct order  This is reasonable - when you think about it cmake can t know what the correct order is until the linking is successfully completed

User · Answer

Try to add -pthread at the end of the library list in the Makefile    It worked for me

User · Answer

Please add  CFLAGS  -lrt  and LDFLAGS  -lrt

User · Answer

if you are using cmake and used pthreads  try add the following lines  find package Threads  target link libraries   CMAKE THREAD LIBS INIT

User · Answer

You should mention the library on the command line after the object files being compiled    gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init        -g -O2 -export-dynamic -o utilities ovs-dpctl utilities ovs-dpctl o        lib libopenvswitch a         home jyyoo src dpdk build lib librte eal a  home jyyoo src dpdk build lib libethdev a  home jyyoo src dpdk build lib librte cmdline a  home jyyoo src dpdk build lib librte hash a  home jyyoo src dpdk build lib librte lpm a  home jyyoo src dpdk build lib librte mbuf a  home jyyoo src dpdk build lib librte ring a  home jyyoo src dpdk build lib librte mempool a  home jyyoo src dpdk build lib librte malloc a        -lrt -lm -lpthread    Explanation  the linking is dependent on the order of modules  Symbols are first requested  and then linked in from a library that has them  So you have to specify modules that use libraries first  and libraries after them  Like this   gcc x o y o z o -la -lb -lc   Moreover  in case there s a circular dependency  you should specify the same library on the command line several times  So in case libb needs symbol from libc and libc needs symbol from libb  the command line should be   gcc x o y o z o -la -lb -lc -lb

User · Answer

If you are using CMake  there are some ways that you could solve it   Solution 1  The most elegant one  add executable      target include directories      target link libraries target name pthread    Solution 2  using CMake find package  find package Threads REQUIRED    this will generate the flag for CMAKE THREAD LIBS INIT  add executable      target include directories      target link libraries target name   CMAKE THREAD LIBS INIT     Solution 3  Change CMake flags    e g  with C   17  change to other version if you need set CMAKE CXX STANDARD 17  set CMAKE CXX FLAGS    CMAKE CXX FLAGS  -std c  17 -pthread

User · Answer

If using g    make sure that you are not running gcc instead

[gcc] libpthread.so.0: error adding symbols: DSO missing from command line

Examples related to gcc

Examples related to compiler-errors

Examples related to linker

Examples related to undefined-reference