Thank you Sven and Brandon for your help. I'm now able to build 7.10.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-tp5764254p5764259.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
According to https://ghc.haskell.org/trac/ghc/ticket/9720, g++ isn't even
used for building. and "passing in gcc for CXX seems to work fine." Wonder
if that's changed.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-tp5764254p5764257.ht
Sven Panne-2 wrote
> Perhaps there is no C++ compiler installed? Try to add "g++" to your
> "apt-get install" command line.
Is g++ a new requirement? I didn't need it for building 7.8.4.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-
I'm trying to build 7.10.1 RC on Debian Jessie. I get an error:
configure: error: in
`/ghc-7.10.0.20141222/libffi/build/x86_64-unknown-linux-gnu':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
config.log shows:
configure: failed program was:
| /* confdefs.h */
| #define PACKAG
Trying to build 7.8.4 from the source distribution (linux).
make install-strip should work as per trac #1851, and the target does indeed
appear in distrib/Makefile. However, the build uses the top-level Makefile,
which doesn't, leading to
# make install-strip
===--- building phase 0
make -r --no-
Simon Marlow-7 wrote
> Is it just shortage of space, or is there anything else that pushes you
> towards DYNAMIC_GHC_PROGRAMS=NO? Isn't disk space cheap?
Disc space is prohibitively expensive for zero-budget open source projects
deployed to the free tier of cloud computing providers.
We typical
harry wrote
> I need to build GHC 7.8 so that Template Haskell will work without shared
> libraries (due to a shortage of space).
>
> I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and
> associated build options. Is this possibility going to be kept goin
I need to build GHC 7.8 so that Template Haskell will work without shared
libraries (due to a shortage of space).
I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and
associated build options. Is this possibility going to be kept going
forward, or will it be deprecated once d
Linux?
--
View this message in context:
http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5749048.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Gl
John Lato-2 wrote
> I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled
Are you able to use template haskell (and qusiquoting) with this? Don't they
need dynamic libs?
--
View this message in context:
http://haskell.1045720.n5.nabble.com/how-to-compile-non-dynamic-ghc-7-8-2-tp574841
John Lato-2 wrote
> I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled
Are you able to use template haskell (and qusiquoting) with this? Don't they
need dynamic libs?
--
View this message in context:
http://haskell.1045720.n5.nabble.com/how-to-compile-non-dynamic-ghc-7-8-2-tp574841
Johan Tibell-2 wrote
> We now have a (Linux) travis-ci buildbot so we should be able to use
> whatever script that buildbot runs.
Does this mean that the Builder page is also no longer relevant? And if so,
how could a Windows buildbot be set up?
--
View this message in context:
http://haskell.
It having been suggested that a buildbot for Windows may be needed, and it
being possible that I may receive permission from management for setting one
up in my department's server room, I set about attempting to discover what
this actually entails.
A Google search led me to https://ghc.haskell.or
Niklas Larsson wrote
> Seems to me that a less pessimistic solution would be to set up a windows
> buildbot.
We need a meatbot who can fix Windows issues in GHC.
What's the current state with buildbots? Wondering around the wiki led me to
http://darcs.haskell.org/ghcBuilder/builders/, which sugg
I've been getting the impression that a lot of the stickier GHC bugs are
Windows specific, while very few GHC hackers actually use Windows, other
than to ensure that GHC works on it.
Windows is already somewhat of a second-class citizen in Hackage, where
platform-sensitive packages tend to only wo
There hasn't been a HWN since mid-December. I've emailed the editor with no
response, and there doesn't seem to have been any (public) online activity
from him since.
I hope he's OK, but either way, it seems that HWN needs a new editor. Any
volunteers?
--
View this message in context:
http://h
Mikhail Glushenkov-2 wrote
> Austin promised to provide us with build bots for 3/4 of the tier 1
> platforms. I assume that he is busy with preparing with the 7.8
> release now.
How often is cabal-install released? Requiring a dedicated buildbot seems
like an overkill just for publishing binaries.
If I use the gold linker with 7.8.1rc2 (RHEL bindist), anything using network
in build-depends - even if it's not used in the code - fails to build with:
libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined reference to
'sem_unlink'
libHSunix-2.7.0.1-ghc7.8.0.20140228.so: error: undefined refe
Should the binary distribution be stripped? Not a huge deal, but I'm saving a
fair amount of space by stripping
http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-x86_64-unknown-linux-rhel65.tar.bz2
after installing it.
--
View this message in context:
http://haskell.1045720.n5.nabble
Carter Schonwald wrote
> Let's not get off track :-). I'm pretty sure some folks occasionally need
> to do profiling/perf debugging on a live server.
>
> So you support there being some easy way to get ghc and cabal-install
> together or no? (Heroku is a good example I guess)
If the only differe
Carter Schonwald wrote
> b) some sort of platform-lite thats the ghc bin dist + cabal-install,
> targeted at folks using haskell on server rather than desktop envs --
> there
> was a bunch of strong support for this (esp those using haskell and aren't
> on the major linux distros)
Would like the p
Something that works on CentOS 6.5 would be much appreciated, thank you.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/target-audience-for-the-binary-distribution-tp5743588p5743762.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
__
Michael Snoyman wrote
> When upgrading to a new version of GHC, you'll have to reinstall all of
> the
> packages anyway. You can't simply use GHC 7.6 compiled packages with your
> new GHC 7.8.
This is probably the point at which it would be useful to know that all this
recompilation will have to b
Carter Schonwald wrote
> Yes. (And thence ghc itself is then invoked with dynamic or dynamic-too)
>
>> The docs for 7.8.1 say "Template Haskell must now load dynamic object
>> files,
>> not static ones". Does this mean that, if I'm using Template Haskell,
>> every
>> package which the templates d
I'm unable to install the binary distribution of 7.8.1 on RHEL because it
requires libgmp.so.10 and GLIBC_2.15, which are much greater than the
version available on Red Hat. (I'm on a shared system without root access,
so upgrading libc is out of the question, even if it could be done.) If this
is
The docs for 7.8.1 say "Template Haskell must now load dynamic object files,
not static ones". Does this mean that, if I'm using Template Haskell, every
package which the templates depend on have to be built with --enable-shared?
--
View this message in context:
http://haskell.1045720.n5.nabble
> Would it be possible for the bindist to link to libgmp.so instead of
libgmp.so.10? Are you expecting core dumps with the wrong version?
I tried faking it, and now it's complaining about GLIBC_2.15. Seems like I
might just have to build from source on Red Hat.
--
View this message in context:
Would it be possible for the bindist to link to libgmp.so instead of
libgmp.so.10? Are you expecting core dumps with the wrong version?
--
View this message in context:
http://haskell.1045720.n5.nabble.com/ANNOUNCE-GHC-7-8-1-Release-Candidate-1-tp5743256p5743506.html
Sent from the Haskell - Gla
http://www.haskell.org/ghc/dist/current/dist/ and
http://www.haskell.org/ghc/dist/stable/dist/ are empty. Is this correct?
--
View this message in context:
http://haskell.1045720.n5.nabble.com/empty-stable-and-current-bindist-directories-tp5743464.html
Sent from the Haskell - Glasgow-haskell-us
Brandon Allbery wrote
> I don't understand the question. Whether a library is split-objs or not
> does not affect how you link an executable, only the space/time efficiency
> trade-off of doing so. And while in theory you might see improvements by
> split-objs-ing an executable, it doesn't make a w
The documentation for --split-objs states that "this only makes sense for
libraries". How is an executable compiled against a split-objs library?
According to
https://github.com/haskell/cabal/issues/1611#issuecomment-30750655, this
isn't happening by default.
--
View this message in context:
ht
I'm trying to use GHC with the gold linker. This is what I get:
ghc Main -pgml ld.gold
Linking Main ...
ld.gold: error: cannot find -lrt
ld.gold: error: cannot find -lutil
ld.gold: error: cannot find -ldl
ld.gold: error: cannot find -lgmp
ld.gold: error: cannot find -lm
ld.gold: error: cannot find
harry wrote
> $ ghc-pkg check --package-db=~/cabal
> ghc-pkg: ~/cabal: openFile: does not exist (No such file or directory)
> $ ls ~/cabal
> package.cache
Ah, the ~ seems to have been tripping it up. Thank you.
--
View this message in context:
http://haskell.1045720.n5.nabbl
Albert Y. C. Lai wrote
> On 13-07-25 03:14 PM, harry wrote:
>> How can I change the location that ghc and ghc-pkg use for the user's
>> package
>> directory? I'm running GHC in a very restricted environment where I don't
>> have access to $HOME, but I ca
How can I change the location that ghc and ghc-pkg use for the user's package
directory? I'm running GHC in a very restricted environment where I don't
have access to $HOME, but I can use specific subdirectories.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/change-locat
Stephen Paul Weber wrote
> You can create the link somewhere else, and use LD_LIBRARY_PATH
> I have done this before. If your version of libgmp is compatible, it
> should
> work.
Thank you - that worked!
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Installing-GHC-and
Brandon Allbery wrote
> Linux ld.so doesn't work that way.
What does the --with-gmp-libraries option do? I've tried using it with a
local shortcut, but it didn't help.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Installing-GHC-and-libgmp-so-tp570p5733351.html
Sent
Stephen Paul Weber wrote
> Somebody claiming to be harry wrote:
>>all of this stems from GHC
>>looking for libgmp.so, instead of libgmp.so.3
>
> Most systems symlink libgmp.so to the default version installed. On
> Debian
> stable it's libgmp.so.10 ... so it ma
I've had a lot of trouble installing the pre-build binary of GHC on various
Linux systems for which packages don't exist - all of this stems from GHC
looking for libgmp.so, instead of libgmp.so.3. Various combinations of
--with-gmp-libraries haven't helped, particularly as I need a packaged build
f
+1 for the -XDotPostfixApply proposal
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Overloaded-record-fields-tp5731998p5733121.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow
Brandon Allbery wrote
> No. The point is, it's not simply a type annotation; it's a *value* (a
> dictionary) that must be carried along with the rest of the value somehow.
> The compiler can't always work out statically which instances need to be
> used with the affected value, so it has to be avai
Sjoerd Visscher-2 wrote
>> class Foo f where
>>foo :: a -> f a
>>
>> data Bar f a = Foo f => Bar {bar :: f a}
>>
>> instance Foo (Bar f) where
>>foo a = Bar (foo a)
>
> No, you can only omit it where you provide Foo f in another way.
Which brings me back to my original question - is the
Sjoerd Visscher-2 wrote
> equal pair@Pair{} = foo pair == bar pair
Interesting solution, I didn't know you could do that. (Do all those who
suggested GADTs - you can add a type context to the constructor of a regular
data type as well, they don't bring you anything here.)
I've also been experienc
All of the proposed solutions seem to rely on pattern matching in the
constructor, which isn't always feasible. Here's a slightly better example:
data Pair a = (Num a, Eq a) => Pair {x::a,y::a}
equal :: Pair a -> Bool
equal pair = (foo pair) == (bar pair)
foo pair = (x pair) * (y pair)
bar pair
data Eq a => Pair a = Pair {x::a, y::a}
equal :: Pair a -> Bool
equal pair = (x pair) == (y pair)
This code will fail to compile, even with the deprecated DatatypeContexts
extension, because equal must be given the Eq a => constraint, even though
this has already been declared on the Pair type.
(I posted the following to gmane.comp.lang.haskell.glasgow.bugs, but I think
that might have been the wrong list.)
I was recently having some trouble building a package through an IDE. When I
tried it from the command line, GHC popped up the following dialogue box:
ghc.exe - Entry Point Not Found
46 matches
Mail list logo
