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

[renxinhe]

I'm trying to build the demo by running make in FleX/demo/compiler/makelinux64. However, I keep running into this linking error, and I couldn't figure out the reason after 30 mins of Googling.

$ make
/usr/bin/ld: ../../../external/SDL2-2.0.4/lib/x64//libSDL2.a(SDL_syssem.o): undefined reference to symbol 'sem_getvalue@@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
make: *** [../../../bin/linux64/NvFlexDemoDebugCUDA_x64] Error 1

Seems like it has to do with libpthread not linking properly. I added

FLAGS = -L /lib64
LIBS = -lusb-1.0 -l pthread

to the beginning of Makefile as this StackOverflow link has suggested, and it doesn't work.

The README doesn't say much about building FleX on Linux, so I assumed this Makefile is the way to go. Please let me know if I'm doing completely the wrong thing.

[mmacklin]

Please try modifying the Makefile.flexDemoCUDA.mk ln57 as follows:

flexDemoCUDA_release_lflags += -g -L../../../external/glew/lib/linux -L/usr/lib -L"../../../lib/linux64" -L$(CUDA_PATH)/lib64 -L../../../external/SDL2-2.0.4/lib/x64/ -pthread -lGL -lglut -lGLU -lGLEW -lcudart_static -ldl -lrt

The order of linker libraries is important here. We'll fix this in the next release.

[renxinhe]

Thanks for the reply. I removed the Stack Overflow suggested change:

FLAGS = -L /lib64
LIBS = -lusb-1.0 -l pthread

from Makefile, and added your suggested change in Makefile.flexDemoCUDA.mk by replacing line 57 with the above. Yet, I'm still getting the same error:

$ make
/usr/bin/ld: ../../../external/SDL2-2.0.4/lib/x64//libSDL2.a(SDL_syssem.o): undefined reference to symbol 'sem_getvalue@@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
make: *** [../../../bin/linux64/NvFlexDemoDebugCUDA_x64] Error 1

---

Below is my CUDA settings in .bashrc. Do I need to set CUDA_PATH somewhere? I noticed that variable name getting referenced in the Makefiles.
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64"
export CUDA_HOME=/usr/local/cuda8.0
export PATH=$PATH:/usr/local/cuda/bin

Also, I made sure to check /lib/x86_64-linux-gnu/libpthread.so.0 and the binary file is indeed in my Linux system.

[mmacklin]

Yes you would need to have CUDA_PATH set in your environment.

There is some indication that the order of libraries on the linker command line is involved, so you could try for instance putting -pthread as the final option. What Linux distro/version are you using?

[renxinhe]

Is CUDA_PATH the same as CUDA_HOME? The CUDA installation guide only mentions LD_LIBRARY_PATH and CUDA_HOME. I did some research on CUDA_PATH, and all the answers I got are for setting $PATH.

---

I'll give putting -pthread last on the linker command a try and let you know if that works.

---

I'm using Ubuntu 14.04 (Trusty Tahr).

[renxinhe]

Update on this issue. It seems like setting CUDA_PATH to be the same as CUDA_HOME fixes the pthread issue. There was no need to put -pthread at the end of the line.

I'm now running into an issue where make complains nvcc not found when I clearly have a symlink /usr/local/cuda8.0/bin/nvcc to /usr/bin/nvcc.

$ make
/usr/local/cuda8.0/bin/nvcc -O3 -g -arch=sm_30 -m64 -Xcompiler -fPIC -D_FORCE_INLINES -I../../.. -I../../../external -I/usr/local/cuda8.0/include -I../../../external/cub-1.3.2 --compile ./../../../extensions/cuda/flexExt.cu -o build/flexExtCUDA_debug/cuda/extensions/cudaflexExt.o
/bin/sh: 1: /usr/local/cuda8.0/bin/nvcc: not found
make: *** [build/flexExtCUDA_debug/cuda/extensions/cudaflexExt.o] Error 127
$ which nvcc
/usr/bin/nvcc

I'll look more into this issue. It may indeed be some dependency issue.

[renxinhe]

Another update. I've resolved the issues above. There were two issues:

1. I didn't have a CUDA_PATH env variable. The CUDA installation guide only mentioned CUDA_HOME, but this demo's Makefiles use CUDA_PATH instead.
2. I had a typo in setting CUDA_PATH. I used /usr/local/cuda8.0 instead of /usr/local/cuda-8.0.

After doing the above two steps, Make was able to run for much longer... until it hit another DSO missing error. I think we are closer to the solution this time though!

$make
...
flexDemoCUDA: compiling debug ./../../../core/tga.cpp...
flexDemoCUDA: compiling debug ./../../../core/voxelize.cpp...
/usr/bin/ld: /usr/local/cuda-8.0/lib64/libcudart_static.a(libcudart_static.a.o): undefined reference to symbol 'pthread_condattr_setpshared@@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
make: *** [../../../bin/linux64/NvFlexDemoDebugCUDA_x64] Error 1

Perhaps I need to modify some other linker flags in some other Makefiles?

[djbutler]

@renxinhe Were you ever able to get this compiled on Ubuntu?

[renxinhe]

@djbutler nope.

[djbutler]

Gotcha. I'm on 16.04, seeing the same error.

[mmacklin]

Hi guys, sorry I don't have an update on this yet.

I can say that we build it internally on Ubuntu 14.04, and even 12.04 LTS. I don't think we've tried 16.04 here, but it seems like this is due to some other configuration difference.

I'll try to find someone to look at this for the next release, but if you find a solution in the meantime please let me know.

[djbutler]

Okay thanks @mmacklin. A little README section on the steps for building for Linux would be great too - perhaps we're missing something obvious.

[djbutler]

Also worth noting - I can't even run the Linux binary. I've added FleX/lib/linux64 and FleX/external/glew/lib/linux to my LD_LIBRARY_PATH, but it fails here.

[djbutler]

I got it to compile. My Makefile.flexDemoCUDA.mk ln57 was changed to:

flexDemoCUDA_release_lflags += -g -L../../../external/glew/lib/linux -L/usr/lib -L"../../../lib/linux64" -L../../../external/SDL2-2.0.4/lib/x64/ -L$(CUDA_PATH)/lib64 -lGL -lglut -lGLU -lGLEW -lcudart_static -ldl -lrt -pthread

and ln42 was changed to:

flexDemoCUDA_release_libraries += :NvFlexDeviceRelease_x64.a

Now I can run make release to completion. However, I still can't run FleX/bin/linux64/NvFlexDemoReleaseCUDA_x64; it still fails when trying to create a CUDA context here.

I'm running this on 16.04, with CUDA V8.0.61. Looks like maybe my CUDA version is too recent - I didn't notice before that it needs to be 8.0.44?

[mmacklin]

Thanks Dan,

Was the change to ln42 necessary? It looks like that would just re-arrange the order of Flex libraries to make the NvFlexDeviceRelease_x64.a appear after NvFlexExtReleaseCUDA_x64.a. I'm not sure why that would affect it, but the first change (to ln57) moves SDL before CUDA which could indeed be the culprit.

Regarding runtime issues, what kind of GPU do you have? Have you run other CUDA apps successfully on this machine?

If so, then you can try commenting out this whole section from main.cpp:

// use the PhysX GPU selected from the NVIDIA control panel	
 	if (g_device == -1)
		g_device = NvFlexDeviceGetSuggestedOrdinal();
		
	// Create an optimized CUDA context for Flex and set it on the 
	// calling thread. This is an optional call, it is fine to use 
	// a regular CUDA context, although creating one through this API
	// is recommended for best performance.
	bool success = NvFlexDeviceCreateCudaContext(g_device);
	
	if (!success)
	{
		printf("Error creating CUDA context.\n");
		exit(-1);
	}

That will mean the demo will create a 'default' CUDA context. Let me know if it helps.

[djbutler]

I'm just getting around to trying this again now.
The good news is, by following your suggestion I can at least compile and run the demo now on 16.04. The bad news is, the GUI sidebar is missing text labels, so I have to blindly click around. Many scenes cause seg faults, but others work fine.
Regarding whether the change to ln42 of Makefile.flexDemoCUDA.mk is necessary - in my version of the file, my edit wasn't a re-arrangement, because NvFlexExtReleaseCUDA_x64.a appeared twice and NvFlexDeviceRelease_x64.a did not appear at all. So I changed the second appearance of "Ext'" to "Device".

At this stage I probably have enough to go on, but if you have any insights into why some of the scenes crash, that would be great.