Re: Libtool generating flags incompatible with nvcc

[Mahesh N]

Hello Ralf

On Tue, Sep 22, 2009 at 12:51 AM, Ralf Wildenhues <address@hidden> wrote:

Hello Mahesh,

first off, please don't top-post, thank you.

I apologize for top-posting. Frankly, I did not know about it earlier. Thanks.
 

> 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'
.
.
.


test1.c is a standalone application that uses the generated shared library for some of its needs.

To avert this, I manually edited the lines in libtool.sh (detailed below - there I made $CC as gcc) to use gcc during the linking stage and the generated shared library when linked with the standalone application, it did not produce any such 'undefined reference' error and worked perfectly ok. I am detailing below, the changes I would like to be made to libtool.sh (to specify an optional linker)

-------- This is originally present in libtool.sh ---------------

# Commands used to build a shared archive.
archive_cmds="\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname \$wl\$soname -o \$lib"
archive_expsym_cmds="echo \\\"{ global:\\\" > \$output_objdir/\$libname.ver~
        cat \$export_symbols | sed -e \\\"s/\\\\(.*\\\\)/\\\\1;/\\\" >> \$output_objdir/\$libname.ver~
        echo \\\"local: *; };\\\" >> \$output_objdir/\$libname.ver~
        \$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname \$wl\$soname \${wl}-version-script \${wl}\$output_objdir/\$libname.ver -o \$lib"

Observe that $CC is used in building the archives and this limits the options we have to generate shared library using another linker or rather leaves us with no option to choose a linker of our own just as we can specify our compiler choice in AC_PROG_CC

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.

 

> But, such a thing does not happen when gcc is used during the linking stage.

Thanks,
Ralf

I am sorry if I have complicated things a bit.


Cheers!
Mahesh