Re: Libtool generating flags incompatible with nvcc

[Ralf Wildenhues]

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