Libpthread so 0 error adding symbols dso missing from command line

asked Nov 11, 2013 at 8:33

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

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.

answered Mar 10, 2019 at 10:18

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.

answered Nov 26, 2013 at 0:34

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<name>, you never know whether it will take lib<name>.so or lib<name>.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

answered Jul 14, 2016 at 13:34

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

answered Aug 29, 2016 at 16:43

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.

answered Dec 17, 2013 at 19:30

AhrBAhrB

1111 silver badge3 bronze badges

biendltbbiendltb

1,0591 gold badge12 silver badges20 bronze badges

answered Apr 13, 2017 at 8:16

Jason GengJason Geng

591 silver badge8 bronze badges

answered Nov 21, 2019 at 8:57

bowman hanbowman han

1,07715 silver badges23 bronze badges

answered Dec 4, 2016 at 18:41

answered Jun 21, 2018 at 22:46

alienflowalienflow

3806 silver badges19 bronze badges

asked Nov 11, 2013 at 8:33

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

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.

answered Mar 10, 2019 at 10:18

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.

answered Nov 26, 2013 at 0:34

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<name>, you never know whether it will take lib<name>.so or lib<name>.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

answered Jul 14, 2016 at 13:34

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

answered Aug 29, 2016 at 16:43

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.

answered Dec 17, 2013 at 19:30

AhrBAhrB

1111 silver badge3 bronze badges

biendltbbiendltb

1,0591 gold badge12 silver badges20 bronze badges

answered Apr 13, 2017 at 8:16

Jason GengJason Geng

591 silver badge8 bronze badges

answered Nov 21, 2019 at 8:57

bowman hanbowman han

1,07715 silver badges23 bronze badges

answered Dec 4, 2016 at 18:41

answered Jun 21, 2018 at 22:46

alienflowalienflow

3806 silver badges19 bronze badges