FAQ
I am trying to invoke CUDA C functions from Go by using cgo. This requires
the CUDA libraries libcuda.so and libcudart.so to be linked in.
All the files compile just fine.

The problem occurs when you pack everything into an archive and invoke 6l
to perform the final llinking. Apparently, some of the library functions
call atexit. And 6l errors with
atexit(0) : Undefined
I see that the same problem was discussed here:
https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/00xWO1lmzEc
However, the solution that the person used (modifying the library) is not
feasible in our case as CUDA is closed source. Furthermore, including
/usr/lib/libc_nonshared.a on the 6l link line doesn't work.

We also tried using the -I and -r flags as specified in the documentation
(-I /usr/lib/ld-linux.so.2 -r /usr/lib64:/opt/nvidia/lib64) so that 6l
links against the CUDA standard headers, but that doesn't seem to help.

--

Search Discussions

  • Ian Lance Taylor at Nov 13, 2012 at 10:29 pm

    On Mon, Nov 12, 2012 at 5:45 PM, wrote:
    I am trying to invoke CUDA C functions from Go by using cgo. This requires
    the CUDA libraries libcuda.so and libcudart.so to be linked in.
    All the files compile just fine.

    The problem occurs when you pack everything into an archive and invoke 6l to
    perform the final llinking. Apparently, some of the library functions call
    atexit. And 6l errors with
    atexit(0) : Undefined
    I see that the same problem was discussed here:
    https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/00xWO1lmzEc
    However, the solution that the person used (modifying the library) is not
    feasible in our case as CUDA is closed source. Furthermore, including
    /usr/lib/libc_nonshared.a on the 6l link line doesn't work.

    We also tried using the -I and -r flags as specified in the documentation
    (-I /usr/lib/ld-linux.so.2 -r /usr/lib64:/opt/nvidia/lib64) so that 6l links
    against the CUDA standard headers, but that doesn't seem to help.
    If you are linking against libcuda.so, then it's not clear to me why
    6l is ever going to see an object that calls atexit. Aren't all those
    objects going to be in libcuda.so, and therefore not subject to
    relinking?

    Ian

    --
  • Neil Deshpa at Nov 14, 2012 at 1:01 am
    I don't explicitly call exit in my .cu file. However, I can see that it's
    an undefined symbol in my object file that is generated by nvcc. So, I
    suspect that nvcc may be adding it to the object code.
    On Tuesday, November 13, 2012 5:29:55 PM UTC-5, Ian Lance Taylor wrote:

    On Mon, Nov 12, 2012 at 5:45 PM, <neil....@gmail.com <javascript:>>
    wrote:
    I am trying to invoke CUDA C functions from Go by using cgo. This requires
    the CUDA libraries libcuda.so and libcudart.so to be linked in.
    All the files compile just fine.

    The problem occurs when you pack everything into an archive and invoke 6l to
    perform the final llinking. Apparently, some of the library functions call
    atexit. And 6l errors with
    atexit(0) : Undefined
    I see that the same problem was discussed here:
    https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/00xWO1lmzEc
    However, the solution that the person used (modifying the library) is not
    feasible in our case as CUDA is closed source. Furthermore, including
    /usr/lib/libc_nonshared.a on the 6l link line doesn't work.

    We also tried using the -I and -r flags as specified in the
    documentation
    (-I /usr/lib/ld-linux.so.2 -r /usr/lib64:/opt/nvidia/lib64) so that 6l links
    against the CUDA standard headers, but that doesn't seem to help.
    If you are linking against libcuda.so, then it's not clear to me why
    6l is ever going to see an object that calls atexit. Aren't all those
    objects going to be in libcuda.so, and therefore not subject to
    relinking?

    Ian
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 13, '12 at 4:27a
activeNov 14, '12 at 1:01a
posts3
users2
websitegolang.org

2 users in discussion

Neil Deshpa: 2 posts Ian Lance Taylor: 1 post

People

Translate

site design / logo © 2022 Grokbase