George Colpitts wrote:
[...]
- When using ghci with 7.10.1 RC1 I get the following errors
intermittently. Is anybody else seeing these?
[...]
- ld: library not found for -l:ghc31505_10.dylib
collect2: error: ld returned 1 exit status
phase `Linker' failed (exitcode =
Thanks Peter
On Mon, Jan 19, 2015 at 7:04 AM, Peter Trommler
peter.tromm...@ohm-hochschule.de wrote:
George Colpitts wrote:
[...]
- When using ghci with 7.10.1 RC1 I get the following errors
intermittently. Is anybody else seeing these?
[...]
- ld: library not found for
Thanks Peter, I think this problem is unique to 10.10.1 on MacOS.
In any case, due to it 7.10.1 RC1 is relatively useless to me. Is there a
script to uninstall? There is a make install so I was hoping make uninstall
would do the right thing but it doesn't seem to. I think I figured out how
to
Eric, thanks for the quick response, that is good news that you are not
seeing the problems I see.
However after I rebuilt with Apple gcc and still see the errors when
calling main from ghci.
One is an open ticket, https://ghc.haskell.org/trac/ghc/ticket/9277# which
was reported in versions
- Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My
problem is described below.
- Which is the recommended gcc to use when building source?
- GNU gcc 4.9.2
- Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
- When using ghci with 7.10.1 RC1 I
On 17 January 2015 at 00:46, Austin Seipp aus...@well-typed.com wrote:
This was a result of https://ghc.haskell.org/trac/ghc/ticket/9652,
which Edward fixed and I'll be merging into the 7.10 branch for RC2.
Thanks Austin, looks like it is already merged in current ghc-7.10 branch:
I managed to
On 23 December 2014 at 23:36, Austin Seipp aus...@well-typed.com wrote:
We are pleased to announce the first release candidate for GHC 7.10.1:
Thanks!
Maybe this is already fixed in git, but it seems to me that RC1 is not able
to build itself?
ghc-cabal: '/usr/bin/ghc-pkg' exited
Hi Jens,
This was a result of https://ghc.haskell.org/trac/ghc/ticket/9652,
which Edward fixed and I'll be merging into the 7.10 branch for RC2.
On Fri, Jan 16, 2015 at 7:19 AM, Jens Petersen juhpeter...@gmail.com wrote:
On 23 December 2014 at 23:36, Austin Seipp aus...@well-typed.com wrote:
Only problem remaining is compiling with -fllvm and running resulting
executable
Other problems below have now been solved:
- cpphs - new version resolves problem
- cabal install vector - upgrade to gcc (Homebrew gcc 4.9.2_1) 4.9.2
solves problem
On Thu, Jan 1, 2015 at 9:58 AM,
I built from source on Mac OS and found the following issues:
- llvm , compiling with llvm (3.4.2) gives the following warnings:
- $ ghc -fllvm cubeFast.hs
[1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o )
clang: warning: argument unused during compilation:
Thanks, there seems to be dependency issues:
cabal install --allow-newer=base -j3 cabal-install
Resolving dependencies...
In order, the following would be installed:
deepseq-1.3.0.2 (latest: 1.4.0.0) (new version)
bytestring-0.10.4.1 (new version)
containers-0.5.6.2 (reinstall) changes:
On 2015-01-01 at 14:58:40 +0100, George Colpitts wrote:
I built from source on Mac OS and found the following issues:
[...]
- cabal install cpphs fails:
-cabal install cpphs
Resolving dependencies...
Configuring cpphs-1.13...
Building cpphs-1.13...
Try
cabal install --allow-newer=base -j3 cabal-install
Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the
upper bound on the base dependency if 1.20 is indeed compatible with the
latest base.
On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts george.colpi...@gmail.com
$
cabal update
Downloading the latest package list from hackage.haskell.org
Note: *there is a new version of cabal-install available.*
To upgrade, run: cabal install cabal-install
bash-3.2$ *cabal install -j3 cabal-install *
*...*
*Resolving dependencies...cabal: Could not resolve
On 1 Jan 2015, at 13:58, George Colpitts wrote:
Configuring cpphs-1.13...
Building cpphs-1.13...
Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
Could not find module ‘Prelude’
It is a member of the hidden package ‘base-4.8.0.0’.
Perhaps you need to add ‘base’ to
however still fails to install but now due to problems with cabal itself
[76 of 76] Compiling Main (
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv0gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/setup.hs,
Oh, because Cabal HQ hasn't cut a release yet.
Try installing out of Git. https://github.com/haskell/cabal/
Edward
Excerpts from George Colpitts's message of 2015-01-01 14:23:50 -0500:
I still have 7.8.3 but it doesn't seem to want to build the latest cabal:
ghc --version
The Glorious
I still have 7.8.3 but it doesn't seem to want to build the latest cabal:
ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
bash-3.2$ cabal install cabal-install
Resolving dependencies...
Configuring cabal-install-1.20.0.6...
Building cabal-install-1.20.0.6...
following solves dependency problems, added a few more packages, thanks!
cabal install
--allow-newer=base,bytestring,deepseq,unix,process,time,random -j3
cabal-install
On Thu, Jan 1, 2015 at 2:27 PM, George Colpitts george.colpi...@gmail.com
wrote:
Thanks but that doesn't seem to work
If you still have your old GHC around, it will be much better to
compile the newest cabal-install using the *old GHC*, and then
use that copy to bootstrap a copy of the newest cabal-install.
Edward
Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
$
cabal update
Thanks but that doesn't seem to work either:
cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
cabal-install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: cabal-install-1.20.0.6 (user goal)
trying: base-4.8.0.0/installed-779... (dependency of
Hi,
On 1 January 2015 at 19:00, George Colpitts george.colpi...@gmail.com wrote:
Thanks, there seems to be dependency issues:
Try also adding '--allow-newer=bytestring,deepseq'.
___
ghc-devs mailing list
ghc-devs@haskell.org
Thanks, I seem to have got that to work
On Thu, Jan 1, 2015 at 3:37 PM, Edward Z. Yang ezy...@mit.edu wrote:
Oh, because Cabal HQ hasn't cut a release yet.
Try installing out of Git. https://github.com/haskell/cabal/
Edward
Excerpts from George Colpitts's message of 2015-01-01 14:23:50
| If I understand correctly, OverloadedRecordFields has not been merged
| yet. Are there any chances to merge it into GHC 7.10.1?
I'm afraid not. The situation is that Adam has a fairly complete patch for
overloaded record fields, but neither he nor I are happy with it. It makes some
fairly
Hello lonetiger,
I don't think any relevant logic changed in 7.10; however, this
commit may be relevant:
commit 8fb03bfd768ea0d5c666bbe07a50cb05214bbe92
Author: Ian Lynagh ig...@earth.li Sun Mar 18 11:42:31 2012
Committer: Ian Lynagh ig...@earth.li Sun Mar 18 11:42:31 2012
Hi Edward,
You’re right, this is my mistake, I am compiling x86_64 Windows, I have not
updated my tools to work on it yet so I’ve been using the x86_32 binaries and
didn’t noticed that my msys2 was compiling a 64bit version.
That explains the warning, sorry for the false alarm!
Regards,
*From:* Austin Seipp mailto:aus...@well-typed.com
*Sent:* Tuesday, December 23, 2014 15:36
*To:* ghc-devs@haskell.org mailto:ghc-devs@haskell.org,
glasgow-haskell-us...@haskell.org mailto:glasgow-haskell-us...@haskell.org
We are pleased to announce the first release candidate for GHC
On 2014-12-28 at 04:41:45 +0100, cg wrote:
[...]
Besides downloading a tarball, can I checkout it using git?
I tried using sync-all as described on wiki [1] to checkout it:
./sync-all checkout ghc-7.10
but it seems it doesn't work, there are error message like:
error: pathspec 'ghc-7.10'
Hi,
I’ve had some issues building this (and the git HEAD), it seems that the
config.guess and config.sub in the libffi tarball is old, it doesn’t detect the
platform when building with msys2. I had to unpack the tarfile and update the
files, after this it correctly built.
Then I proceeded
Kazu Yamamoto kazu at iij.ad.jp writes:
No, it is a big change and the merge window is closed now. This question
was just asked on reddit:
http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/
Greg, thank you for this info. But it is really
Perhaps the readers of this list could read the reddit comments
and propose a way forward?
I tried to compile orf-new on Mac (Yosemite). orf-new cannot be
compiled even after git submodule update --init. After modifying
some code (e.g. ASSERT macros), it still fails on CMM part. I think
that
We are pleased to announce the first release candidate for GHC 7.10.1:
https://downloads.haskell.org/~ghc/7.10.1-rc1/
This includes the source tarball and bindists for 64bit/32bit Linux
and Windows. Binary builds for other platforms will be available
shortly. (CentOS 6.5 binaries are not
Hi,
If I understand correctly, OverloadedRecordFields has not been merged
yet. Are there any chances to merge it into GHC 7.10.1?
--Kazu
We are pleased to announce the first release candidate for GHC 7.10.1:
https://downloads.haskell.org/~ghc/7.10.1-rc1/
This includes the source
No, it is a big change and the merge window is closed now. This question
was just asked on reddit:
http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/
On Tue, Dec 23, 2014 at 6:12 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hi,
If I understand
No, it is a big change and the merge window is closed now. This question
was just asked on reddit:
http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/
Greg, thank you for this info. But it is really disappointing.
I was silent about this because it
35 matches
Mail list logo