libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libtool and CUDA


From: Ralf Wildenhues
Subject: Re: Libtool and CUDA
Date: Mon, 6 Dec 2010 22:25:18 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Peter,

* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 02:49:23PM CET:
> On 12/06/2010 01:07 AM, Ralf Wildenhues wrote:
> >>>OK to apply?
> >>
> >>Unless Pawel reports that it works for him, no. This doesn't make
> >>sense to me.

> >Why?
> 
> Well, perhaps I haven't been drinking enough coffee, but...

Hehe.

> >>>        _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
> 
> This assignment didn't work, or was overwritten later.

Where do you see that?  As far as I understand, PaweĊ‚ hasn't actually
tried configuring Libtool with something like
  ./configure CC=nvcc

because then the assignment will work.

> >>>-      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
> 
> So, why will this make any difference?

See above.

> >>>+      if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
> >>>+        _LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
> >>>$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
> >>>+      fi

Of course the whole support currently won't work if you need to have
both compilers CC=gcc and, say, NVCC=nvcc or so; to workaround you
currently need a subpackage with a sub configure script where you
override CC=$NVCC.

We could fix that in the same way as the proposed Go patch: by
explicitly introducing a new language called Cuda or so.  I'm not
disinclined, but since there exists no free version of this compiler
this might politically be a bit "interesting", to say the least.

I was wrong a bit in my last message though: the manual for version 2.0
does document --shared and -shared, and mentions that other flags
necessary for shared libraries need to be passed through with
-Xcompiler.  Which matches my proposed patch.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]