Dynamic shared library


I’m a phd student and i’m developing a global illumination application with CUDA.

I develop under Ubuntu Hardy Heron x86_64 with :

  • gcc 4.1.3;
  • CUDA 1.1 toolkit ;
  • 169.12 NVidia driver.

When i try to use CUDA in a dynamically loaded shared library, it doesn’t work.

The program and his library are successfully compiled and linked, but when i run it, CUDA doesn’t seem to work…

So i reproduce the bug on simpleGL (see attachment). If i use the “same” source code in a single executable, it works, else it does nothing.

I can’t do that with my real project. <img src=‘http://hqnveipbwb20/public/style_emoticons/<#EMO_DIR#>/crying.gif’ class=‘bbc_emoticon’ alt=’:’(’ />

Do you have any ideas ? Is it a CUDA bug ?

simpleGL.tar.gz (2.9 KB)

All you’ve said is that something “doesn’t seem to work”, yet you’ve not provided any information on what specifically is failing.

What is the failure behavior?
What is the expected behavior?
Please generate and attach an nvidia-bug-report.log.

If you build and run the simpleGL2 and the simpleGL (see attachment), you should see a great “cosine wave” on the first (a simple program from the sdk) and a single red point on the second (program + dynamic library). I can make screenshots if you like.

The only difference between them is the use of a dynamically loaded library.
nvidia_bug_report.tar.gz (31.3 KB)

Any news ?

I’m afraid that its still not clear to me what the failure behavior is that you’re reporting here. How will I know that I’ve reproduced the problem you’re reported?

Sorry, but I don’t understand what isn’t clear.

The example source code isn’t clear ?

Do you want a more complete commentary of the source code ?

What is the actual behavior that you’re seeing? How would I know that I’ve reproduced the problem?

The kernel isn’t called (but the wrapper is) when it’s compiled in a dynamically loaded library. When i use the “same” CUDA source code without a DLL, it works. There are only 3 different lines between the simpleGL project and the simpleGL2 project (the code to load the DLL).
screenshots.tar.gz (22 KB)

I assume that the attached screenshots are the expected behavior rather than the actual behavior ? I was requesting to see a screenshot of what the failure behavior looks like.

Also, your app doesn’t build:
$ make
g++ -Wall -g -fPIC -I/usr/local/cuda/include/ -c -o simpleGL.o simpleGL.cpp
simpleGL.cpp: In function `int main(int, char**)’:
simpleGL.cpp:105: error: ISO C++ forbids casting between pointer-to-function and pointer-to-object
make: *** [simpleGL.o] Error 1

I’m surprised, i can build the two applications without problem with the attached source code.

I did a little mistake on the names in the explications. The simpleGL was the buggy program and the simpleGL2 was the functional program.

I repacked the screenshots and the applications (see the attachment).
ok.tar.gz (25.2 KB)

This app appears to require gcc-4.x to build. I’m able to replicate the problem you reported, and have opened bug 434651 to have it investigated further.

Ok, thanks.

We’ve discovered an error in the ‘with’ makefile in the simpleGL_kernel.so target:

simpleGL_kernel.so: simpleGL_kernel.o
(CXX) (LDFLAGS) -shared -Bsymbolic -nostartfiles simpleGL_kernel.o -o simpleGL_kernel.so

should be:

simpleGL_kernel.so: simpleGL_kernel.o
(CXX) (LDFLAGS) -Xlinker -shared -Xlinker -Bsymbolic -nostartfiles simpleGL_kernel.o -o simpleGL_kernel.so

You failed to correctly pass the “-shared” and “-Bsymbolic” options to the linker.

This does not, however, fix the bug that you reported here, however I wanted you to be aware of the mistake. We’re still investigating the bug.

Thanks, I forgot the -Bsymbolic option to reduce the number of dynamic relocations in
the shared library.

Did you try to reproduce the bug with Cuda 2 ?

Any news ?

This should be fixed in the next release of CUDA after 2.0.

One thing that I should note is that there’s no need to use “-nostartfiles” in your build (or Makefile). Part of the fix for this bug required that that option be removed prior to building your test app.