[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Libtool generating flags incompatible with nvcc
From: |
Ralf Wildenhues |
Subject: |
Re: Libtool generating flags incompatible with nvcc |
Date: |
Thu, 24 Sep 2009 21:13:09 +0200 |
User-agent: |
Mutt/1.5.20 (2009-08-09) |
Hello Mahesh,
* Mahesh N wrote on Thu, Sep 24, 2009 at 06:36:30PM CEST:
> On Tue, Sep 22, 2009 at 12:51 AM, Ralf Wildenhues wrote:
> > first off, please don't top-post, thank you.
> >
> I apologize for top-posting. Frankly, I did not know about it earlier.
No problem of course.
> > > I think there is some symbol stripping happening when nvcc is used to
> > > generate the shared library. When I use the generated shared library with
> > > another project, the compilation fails and the compiler returns with :
> > >
> > > test1.c:(.text+0x58): undefined reference to `gsl_vector_set_all'
> > > test1.c:(.text+0x73): undefined reference to `gsl_vector_get'
> > Please show the full command that fails, starting from '...libtool
> > --mode=link ...' on, including all error output, cut and pasted.
> >
> Basically, when libtool is generating the shared library, there is no error
> and it succeeds. I am getting the 'undefined reference' error only when I am
> using the functions in the generated shared library for a standalone
> application.
>
> eg: if libgslcblas.so is the shared object generated by libtool (after
> applying the patch) and it is installed under /usr/local/lib
>
> $ gcc test1.c -lgslcblas.so -lgsl -lm
> test1.c:(.text+0x58): undefined reference to `gsl_vector_set_all'
> test1.c:(.text+0x73): undefined reference to `gsl_vector_get'
That is interesting, because I don't yet understand why it happens.
It shouldn't be symbol stripping, though; rather, I presume some
mangling or so.
(BTW, you should be able to write -lgslcblas instead of -lgslcblas.so.)
> test1.c is a standalone application that uses the generated shared library
> for some of its needs.
Would it be possible for you to produce a small demo package that
exhibits this problem? You don't need to show your code, it should
be sufficient if test1.c and libgslcblas each only contain one dummy
function that uses a function from the next library. In addition to
the demo package I'd like to see a complete build output from it.
I would like to see this issue happen, and why it happens. Maybe I can
then suggest a different way to avoid the issue, or understand why
Libtool would need the functionality you request.
> So, if nvcc is the compiler we are using, we are forced to use nvcc to build
> the archive too. Instead, if this could be made a bit flexible by allowing
> us to give options in AC_PROG_LIBTOOL and using a separate variable for the
> path to the linker like $CC, that would be a nice thing, I think. When no
> options are specified, the variable can take what $CC contains.
Doing this right there in the libtool script is not easily possible,
because a different link program would need some different results of
some of the configure tests that the Libtool macros run. libtool only
provides (as of now) different --tags for different compilers. But
there might be other options for your issue; see above.
Thanks,
Ralf
- Re: Libtool generating flags incompatible with nvcc, Ralf Wildenhues, 2009/09/02
- Message not available
- Message not available
- Re: Libtool generating flags incompatible with nvcc, Mahesh N, 2009/09/03
- Re: Libtool generating flags incompatible with nvcc, Mahesh N, 2009/09/04
- Re: Libtool generating flags incompatible with nvcc, Ralf Wildenhues, 2009/09/12
- Re: Libtool generating flags incompatible with nvcc, Mahesh N, 2009/09/12
- Re: Libtool generating flags incompatible with nvcc, Ralf Wildenhues, 2009/09/18
- Re: Libtool generating flags incompatible with nvcc, Mahesh N, 2009/09/21
- Re: Libtool generating flags incompatible with nvcc, Ralf Wildenhues, 2009/09/21
- Re: Libtool generating flags incompatible with nvcc, Mahesh N, 2009/09/24
- Re: Libtool generating flags incompatible with nvcc,
Ralf Wildenhues <=