X86 64 linux gnu libpthread so 0

undefined references in libpthread and libc

I’m having trouble compiling some examples in a odbc sdk. After some time mingling with the library order, I somehow managed to get the number of undefined references to just a handful of them. Sadly, I can’t figure out how to get rid of the remaining ones. Here’s the command that’s failing:

g++ -Wall -z defs -m64 -DSIMBA -D_REENTRANT -fPIC -O0 -g -shared Common/TabbedUnicodeFileReader_Linux_x8664_debug.cpp.o Core/QSConnection_Linux_x8664_debug.cpp.o Core/QSDriver_Linux_x8664_debug.cpp.o Core/QSEnvironment_Linux_x8664_debug.cpp.o Core/QSStatement_Linux_x8664_debug.cpp.o DataEngine/QSDataEngine_Linux_x8664_debug.cpp.o DataEngine/QSMetadataHelper_Linux_x8664_debug.cpp.o DataEngine/QSTable_Linux_x8664_debug.cpp.o DataEngine/QSTableUtilities_Linux_x8664_debug.cpp.o DataEngine/QSTypeInfoMetadataSource_Linux_x8664_debug.cpp.o Common/QSTableMetadataFile_Unix_Linux_x8664_debug.cpp.o Common/QSUtilities_Unix_Linux_x8664_debug.cpp.o Main_Unix_Linux_x8664_debug.cpp.o -Wl,--no-undefined -Wl,--no-allow-shlib-undefined -Wl,--whole-archive,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaDSI_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaSupport_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libAEProcessor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libCore_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libDSIExt_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libExecutor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libParser_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaODBC_debug.a -Wl,--no-whole-archive -Wl,--soname=../Bin/Linux_x8664/libQuickstart_debug.so -L/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//ThirdParty/icu/Linux_x8664/lib -licuuc_simba64 -licudata_simba64 -licui18n_simba64 -lpthread -lm -lc -ldl -Wl,--version-script=exports_Linux.map -o ../Bin/Linux_x8664/libQuickstart_debug.so 

/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libdl.so: undefined reference to `_dl_rtld_di_serinfo@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls_init@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__libc_stack_end@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_get_tls_static_info@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__tls_get_addr@GLIBC_2.3' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_deallocate_tls@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_make_stack_executable@GLIBC_PRIVATE' 

Fixed: Removing -Wl,—no-allow-shlib-undefined seemed to do the trick. The built shared library seems to work perfectly.

Источник

Java: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE

I’ve been working on a Java project that uses a gui.jar file to import some classes. Everything was working fine until yesterday. Now, I can compile the .class files by the command javac -d ./bin -sourcepath ./src -classpath ./bin/gui.jar src/simulation/TestSimulateur.javac but when I try to execute the program with java -classpath bin:bin/gui.jar simulation.TestSimulateur I get the error java: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE make: *** [Makefile:47: carte1] Error 127 I don’t know much about how snap and the libraries work so I’m not sure about the root of the problem. It’s strange that the problem only appears when I run it on VSCode, while it works fine if I run it on the normal Linux terminal. I’ve searched a lot but couldn’t find how to solve the problem. As I’ve said, I’m newbie on Linux system. Between my attempts, I tried to reinstall VSCode, updating the system and updating snap packages, but none of those worked.

2 Answers 2

Though I have already answered it here

The issue with how the VSCode Snap package libraries are configured to be used. They are setting the following environment variable GTK_PATH , which gets inherited by the VSCode Terminal.

Unsetting the environment variable in the VSCode terminal does seem to work for me.

As a slightly more permanent workaround, you can also unset GTK_PATH in your VS Code user settings, run «Preferences: Open User Settings (JSON)» and add this to your settings.json :

 "terminal.integrated.env.linux":

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status #637

//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status #637

Comments

While trying to compile matconvnet I get the following error:

/usr/bin/ld: /home/user/libs/matconvnet/matconvnet-1.0-beta20/matlab/mex/.build/bits/impl/tinythread.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 collect2: error: ld returned 1 exit status mex: link of ' "/home/user/libs/matconvnet/matconvnet-1.0-beta20/matlab/mex/vl_nnconv.mexa64"' failed. 

Does anyone have an idea how to fix that?
I’m using Ubuntu 14.04 with Matlab R2013a and CUDA 7.5.

The text was updated successfully, but these errors were encountered:

Источник

Building error using cmake: cannot find -lpthreads

I have c++ project that was smoothly running on a given machine, and now I am trying to compile it on another one with the same operating system (Xubuntu 14.04). I’ve installed all the dependencies and I’am using cmake to build the project, although it stops with the following error:

Determining if the function pthread_create exists in the pthreads failed with the following output: . /usr/bin/ld: cannot find -lpthreads

set(CMAKE_C_FLAGS "$ -O3 -lpthread -DNDEBUG -DEIGEN_MPL2_ONLY") set(CMAKE_C_FLAGS_DEBUG "-g -O0 -Wall -lpthread -DEIGEN_MPL2_ONLY") set(CMAKE_CXX_FLAGS "$ -O3 -lpthread -I/usr/include/freetype2 -DNDEBUG -DEIGEN_MPL2_ONLY") set(CMAKE_CXX_FLAGS_DEBUG "-g -O0 -Wall -lpthread -I/usr/include/freetype2 -DEIGEN_MPL2_ONLY") 

• changed the order of -lpthread in the cmakelists line above, which gives the same error
• used different versions o gcc/g++: tried 4.4, 4.6 and 4.8, without any change
• created a symbolic link to libpthread.so in /usr/lib/, without any change

I would appreciate some help, since I am already short on ideas on what to try next.

The library is where it should:

$ find /lib -name "*pthread*" /lib/x86_64-linux-gnu/libpthread-2.19.so /lib/x86_64-linux-gnu/libpthread.so.0 

The pthread_create is also found:

$ nm /lib/x86_64-linux-gnu/libpthread.so.0 | grep "pthread_create" 0000000000008430 t __pthread_create_2_1 00000000000081430 T pthread_create@@GLIBC_2.2.5 

I have also verified that both libpthread-stubs0 and libc6-dev are present.

This is part of the FindThreads.cmake file content, located in /usr/share/cmake-2.8/Modules/:

if(CMAKE_HAVE_SPROC_H AND NOT CMAKE_THREAD_PREFER_PTHREAD) # We have sproc set(CMAKE_USE_SPROC_INIT 1) else() # Do we have pthreads? CHECK_INCLUDE_FILES("pthread.h" CMAKE_HAVE_PTHREAD_H) if(CMAKE_HAVE_PTHREAD_H) # # We have pthread.h # Let's check for the library now. # set(CMAKE_HAVE_THREADS_LIBRARY) if(NOT THREADS_HAVE_PTHREAD_ARG) # Check if pthread functions are in normal C library CHECK_SYMBOL_EXISTS(pthread_create pthread.h CMAKE_HAVE_LIBC_CREATE) if(CMAKE_HAVE_LIBC_CREATE) set(CMAKE_THREAD_LIBS_INIT "") set(CMAKE_HAVE_THREADS_LIBRARY 1) set(Threads_FOUND TRUE) endif() if(NOT CMAKE_HAVE_THREADS_LIBRARY) # Do we have -lpthreads CHECK_LIBRARY_EXISTS(pthreads pthread_create "" CMAKE_HAVE_PTHREADS_CREATE) if(CMAKE_HAVE_PTHREADS_CREATE) set(CMAKE_THREAD_LIBS_INIT "-lpthreads") set(CMAKE_HAVE_THREADS_LIBRARY 1) set(Threads_FOUND TRUE) endif() # Ok, how about -lpthread CHECK_LIBRARY_EXISTS(pthread pthread_create "" CMAKE_HAVE_PTHREAD_CREATE) if(CMAKE_HAVE_PTHREAD_CREATE) set(CMAKE_THREAD_LIBS_INIT "-lpthread") set(CMAKE_HAVE_THREADS_LIBRARY 1) set(Threads_FOUND TRUE) endif() if(CMAKE_SYSTEM MATCHES "SunOS.*") # On sun also check for -lthread CHECK_LIBRARY_EXISTS(thread thr_create "" CMAKE_HAVE_THR_CREATE) if(CMAKE_HAVE_THR_CREATE) set(CMAKE_THREAD_LIBS_INIT "-lthread") set(CMAKE_HAVE_THREADS_LIBRARY 1) set(Threads_FOUND TRUE) endif() endif() endif() endif() if(NOT CMAKE_HAVE_THREADS_LIBRARY) # If we did not found -lpthread, -lpthread, or -lthread, look for -pthread if("THREADS_HAVE_PTHREAD_ARG" MATCHES "^THREADS_HAVE_PTHREAD_ARG") message(STATUS "Check if compiler accepts -pthread") try_run(THREADS_PTHREAD_ARG THREADS_HAVE_PTHREAD_ARG $ $/Modules/CheckForPthreads.c CMAKE_FLAGS -DLINK_LIBRARIES:STRING=-pthread COMPILE_OUTPUT_VARIABLE OUTPUT) if(THREADS_HAVE_PTHREAD_ARG) if(THREADS_PTHREAD_ARG STREQUAL "2") set(Threads_FOUND TRUE) message(STATUS "Check if compiler accepts -pthread - yes") else() message(STATUS "Check if compiler accepts -pthread - no") file(APPEND $$/CMakeError.log "Determining if compiler accepts -pthread returned $ instead of 2. The compiler had the following output:\n$\n\n") endif() else() message(STATUS "Check if compiler accepts -pthread - no") file(APPEND $$/CMakeError.log "Determining if compiler accepts -pthread failed with the following output:\n$\n\n") endif() endif() if(THREADS_HAVE_PTHREAD_ARG) set(Threads_FOUND TRUE) set(CMAKE_THREAD_LIBS_INIT "-pthread") endif() endif() endif() endif() 

Used a minimal Cmakelists.txt as follows:

cmake_minimum_required (VERSION 2.4) find_package(Threads) 

Which produced the following output:

-- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found. -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE 

Источник