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.)
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.
Sure. No worries. My project is going to be FOSS. I will mail the sample on Monday, 5th October, 2009. I had not been to work the past week. And I dont have a remote login. So I can mail it on Moday , when I would be going to office.
> 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