Jens Petersen wrote:
>> I don't think compat-llvm34 would save you. ghc emits llvm ir directly,
>> then invokes llc to compile it; /usr/bin/llc would only be provided by
>> llvm, not by the compat package which would be just the old library.
>
> I was assuming it would provide all of llvm34 (min
On Thu, 2014-11-06 at 20:51 -0500, Jens Petersen wrote:
> > That's only going to work if llvm34 renames all of its binaries, and ghc
> > is changed to invoke the renamed ones, right? Otherwise the 3.4 and 3.5
> > versions of /usr/bin/llc will conflict.
>
> Hmm yes I guess I should go the whole wa
On Fri, Nov 7, 2014 at 2:51 AM, Jens Petersen wrote:
>> That's only going to work if llvm34 renames all of its binaries, and ghc
>> is changed to invoke the renamed ones, right? Otherwise the 3.4 and 3.5
>> versions of /usr/bin/llc will conflict.
>
> Hmm yes I guess I should go the whole way...
>
> That's only going to work if llvm34 renames all of its binaries, and ghc
> is changed to invoke the renamed ones, right? Otherwise the 3.4 and 3.5
> versions of /usr/bin/llc will conflict.
Hmm yes I guess I should go the whole way...
My initial lazy plan was just that ghc-compiler.armv7hl
shou
On Wed, 2014-11-05 at 21:23 -0500, Jens Petersen wrote:
> > I don't think compat-llvm34 would save you. ghc emits llvm ir directly,
> > then invokes llc to compile it; /usr/bin/llc would only be provided by
> > llvm, not by the compat package which would be just the old library.
>
> I was assumin
> I don't think compat-llvm34 would save you. ghc emits llvm ir directly,
> then invokes llc to compile it; /usr/bin/llc would only be provided by
> llvm, not by the compat package which would be just the old library.
I was assuming it would provide all of llvm34 (minus clang34). :)
I think the
> I think the only way for ARM ghc is to do an llvm34 package.
> (I don't know when ghc will support 3.5 - perhaps for 7.10 which
> is now in development?) ghc only needs llvm.armv7hl (and llvm-libs).
I went ahead and created a llvm34 package.
https://bugzilla.redhat.com/show_bug.cgi?id=1161014
On Wed, 2014-11-05 at 00:44 -0500, Jens Petersen wrote:
> llvm-3.5 seems to break Haskell programs compiled with ghc on ARM badly.
>
> > Perhaps I should just barge ahead with a compat-llvm34?
>
> Adam: this would be very welcome for ghc
> (ghc only needs llvm - not any clang bits).
>
> Otherwis
llvm-3.5 seems to break Haskell programs compiled with ghc on ARM badly.
> Perhaps I should just barge ahead with a compat-llvm34?
Adam: this would be very welcome for ghc
(ghc only needs llvm - not any clang bits).
Otherwise currently we can't build any Haskell packages in Rawhide
because compi
On Tue, 2014-10-21 at 13:33 +0200, Sergio Pascual wrote:
> I have retired python-llvmpy in Rawhide and F21.
> Now if the owner of llvm does the "Obsoletes trick " then the rebase
> can go ahead, is it right?
Hopefully! I still need to get dragonegg building, but that at least
does have an activ
2014-10-21 12:32 GMT+02:00 Kalev Lember :
> On 10/21/2014 10:37 AM, Sergio Pascual wrote:
> > Just a question. If I retire the package in F21, will it affect the F20
> > F21 upgrade path for those
> > who have python-llvmpy installed?
> >
> > I mean, you upgrade, there is a new llvm 3.5, but you h
On 10/21/2014 10:37 AM, Sergio Pascual wrote:
> Just a question. If I retire the package in F21, will it affect the F20
> F21 upgrade path for those
> who have python-llvmpy installed?
>
> I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy
> that requires llvm 3.4
> and... fe
2014-10-20 16:19 GMT+02:00 Adam Jackson :
> On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
> > 2014-10-17 16:00 GMT+02:00 Peter Robinson :
>
> > So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
>
> I would be too, but I'm going to want 3.5 in F21, and we have this wh
>
> i can take a look at llvmpy this week, but i'd recommend just retiring
> it otherwise. it can come back if it has to.
I was going to retire it before, but upstream had a patch,
Its jsut a wrapper aruond the API, it probably needs to be developed
in sync with llvm, and so far I haven't seen
On Mon, Oct 20, 2014 at 10:19:16AM -0400, Adam Jackson wrote:
> On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
> > 2014-10-17 16:00 GMT+02:00 Peter Robinson :
>
> > So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
>
> I would be too, but I'm going to want 3.5 in F21
On 10/20/2014 04:19 PM, Adam Jackson wrote:
> On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
>> 2014-10-17 16:00 GMT+02:00 Peter Robinson :
>
>> So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
>
> I would be too, but I'm going to want 3.5 in F21, and we have this w
On Mon, Oct 20, 2014 at 3:19 PM, Adam Jackson wrote:
> On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
>> 2014-10-17 16:00 GMT+02:00 Peter Robinson :
>
>> So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
>
> I would be too, but I'm going to want 3.5 in F21, and we hav
On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
> 2014-10-17 16:00 GMT+02:00 Peter Robinson :
> So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
I would be too, but I'm going to want 3.5 in F21, and we have this whole
thing about not retiring packages in a live relea
2014-10-17 16:00 GMT+02:00 Peter Robinson :
> On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson wrote:
> > Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for
> > proper ppc64le support, as well as some minor radeonsi features in Mesa.
>
> And massively improved aarch64 support
>
On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson wrote:
> Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for
> proper ppc64le support, as well as some minor radeonsi features in Mesa.
And massively improved aarch64 support
> One problem this time around appears to be python-ll
Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for
proper ppc64le support, as well as some minor radeonsi features in Mesa.
One problem this time around appears to be python-llvmpy, which appears
to have decided that llvm 3.2/3.3 are the only versions it will support:
https:
21 matches
Mail list logo