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 (minus
On Fri, Nov 7, 2014 at 2:51 AM, Jens Petersen peter...@redhat.com 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
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 way...
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
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
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 assuming it
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
should
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).
Otherwise
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
2014-10-20 16:19 GMT+02:00 Adam Jackson a...@redhat.com:
On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
2014-10-17 16:00 GMT+02:00 Peter Robinson pbrobin...@gmail.com:
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
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... fedup
2014-10-21 12:32 GMT+02:00 Kalev Lember kalevlem...@gmail.com:
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
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 active
On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
2014-10-17 16:00 GMT+02:00 Peter Robinson pbrobin...@gmail.com:
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
On Mon, Oct 20, 2014 at 3:19 PM, Adam Jackson a...@redhat.com wrote:
On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote:
2014-10-17 16:00 GMT+02:00 Peter Robinson pbrobin...@gmail.com:
So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
I would be too, but I'm going to
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 pbrobin...@gmail.com:
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
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 pbrobin...@gmail.com:
So I'm OK with retiring python-llvmpy if a patch doesn't appear soon.
I would be too, but I'm going to
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
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:
On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson a...@redhat.com 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
2014-10-17 16:00 GMT+02:00 Peter Robinson pbrobin...@gmail.com:
On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson a...@redhat.com 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
21 matches
Mail list logo
