problem compiling GHC 8.0.1 release candidate 2 src on Apple

") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO")

Re: problem compiling GHC 8.0.1 release candidate 2 src on Apple

George Colpitts writes: snip > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") >

Compiling a cabal project with LLVM on GHC 7.10 RC1

of cabal build -v. I can build a hello world program, just fine with `ghc --make`: $ /usr/local/bin/ghc-7.10.0.20141222 --make -O2 -fllvm Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Thanks, Brandon ___ Glasgow

Re: Compiling a cabal project with LLVM on GHC 7.10 RC1

-fllvm Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Thanks, Brandon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Cross compiling for Cortex A9

? Mike On Aug 4, 2014, at 8:23 AM, Michael Jones m...@proclivis.com wrote: To be complete, there is an old link on compiling for arm, and it recommends this build process: $ chmod ugo+rx build-ghc-arm.sh Edit build-ghc-arm.sh to fix EOF $ ./build-ghc-arm.sh -j4 $ make test $ sudo make

Re: Cross compiling for Cortex A9

To be complete, there is an old link on compiling for arm, and it recommends this build process: $ chmod ugo+rx build-ghc-arm.sh Edit build-ghc-arm.sh to fix EOF $ ./build-ghc-arm.sh -j4 $ make test $ sudo make install $ arm-poky-linux-gnueabi-ghc --info This way of building produces the same

Re: Cross compiling for Cortex A9

IIRC, CFLAGS should be needed only for configure which should detect your architecture well and generate appropriate settings file. GHC itself should not use them IIRC. If you need something special, then you can use mk/build.mk But I'm not expert for cross-compiling GHC, nor for cross

Re: Cross compiling for Cortex A9

On 08/ 2/14 07:04 AM, Michael Jones wrote: ,(target arch,ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}) ,(target word size,4) this looks good, but I hope you got it on clean tree, i.e. without your configure hack... Karel

Re: Cross compiling for Cortex A9

Karel, My configure hack is now limited to two hacks on GHC 7.8.3. The vendor “pokey, and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean. I am getting a stack overflow during execution

Re: Cross compiling for Cortex A9

: unrecognized command line option ‘-mfloat-abi=hard’ gcc: error: unrecognized command line option ‘-mfpu=neon’ make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2 It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2

Re: Cross compiling for Cortex A9

/.depend-v.c_asm] Error 1 make: *** [all] Error 2 It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler. Now, in build.mk I have: BuildFlavour = quick-cross Which

Re: Cross compiling for Cortex A9

option ‘-mfpu=neon’ make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2 It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler. Now

Re: Cross compiling for Cortex A9

command line option ‘-mfpu=neon’ make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2 It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross

Re: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

| -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of cheater00 . | Sent: 21 July 2014 18:51 | To: glasgow-haskell-users@haskell.org | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to | 7.8.3 | | Hi, I

Re: Cross compiling for Cortex A9

make: *** [all] Error 2 It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler. Now, in build.mk I have: BuildFlavour = quick-cross Which is supposed to prevent stage2

Re: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of cheater00 . | Sent: 21 July 2014 18:51 | To: glasgow-haskell-users@haskell.org | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to | 7.8.3 | | Hi, I was experimenting a bit

Re: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

stopped compiling on upgrade from GHC 7.6.3 to | 7.8.3 | | Hi, I was experimenting a bit with type families recently and ran into | a bit of an issue. Given that I don't know type families that well yet, | I was wondering if I made an error somewhere. One thing is that I can't | find any

RE: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of cheater00 . | Sent: 21 July 2014 18:51 | To: glasgow-haskell-users@haskell.org | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to | 7.8.3 | | Hi, I was experimenting a bit with type families recently

RE: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

-users@haskell.org | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to | 7.8.3 | | Hi, I was experimenting a bit with type families recently and ran into | a bit of an issue. Given that I don't know type families that well yet, | I was wondering if I made an error somewhere

Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

Hi, I was experimenting a bit with type families recently and ran into a bit of an issue. Given that I don't know type families that well yet, I was wondering if I made an error somewhere. One thing is that I can't find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. Maybe this

Failure compiling ghc-mtl with ghc-7.8.{2,3}

I was trying to upgrade to ghc-7.8 the other day, and got this compilation failure when building ghc-mtl-1.2.1.0 (see the end of the message). I'm using the haskell overlay on Gentoo Linux straight out of the box, no local cabal installations of anything. Now I was told that other people can

Re: Failure compiling ghc-mtl with ghc-7.8.{2,3}

The last time I saw this error, it was because the package database was messed up (there was an instance of MonadIO in scope, but it was for the wrong package.) However, I don't know what the source of the problem is here. Edward Excerpts from i hamsa's message of 2014-07-20 08:26:52 +0100: I

Re: Failure compiling ghc-mtl with ghc-7.8.{2,3}

I think I found the problem. package ghc-7.8.3 requires transformers-0.3.0.0 package mtl-2.2.1 requires transformers-0.4.1.0 package exceptions-0.6.1 requires transformers-0.4.1.0 I wonder how is this ever supposed to work :( On Sun, Jul 20, 2014 at 9:01 PM, Edward Z. Yang ezy...@mit.edu wrote:

Re: Failure compiling ghc-mtl with ghc-7.8.{2,3}

It looks like you will have to install old versions of mtl/exceptions which work on transformers-0.3.0.0, although undoubtedly the real problem is that GHC should update what version of transformers it is distributing. Edawrd Excerpts from i hamsa's message of 2014-07-20 19:25:36 +0100: I think

Re: Cross compiling for Cortex A9

On 07/12/14 07:27 AM, Michael Jones wrote: Karel, I have failed to figure out how to make this happen: (target arch, ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”) This is result of running ./configure on arm/ubuntu12.04 -- so I don't cross-compile, but rather compile

Re: Cross compiling for Cortex A9

be a good approach. Learn the build system on something known to work. So I probably will not give up on that. That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat... I got a book

Re: Cross compiling for Cortex A9

I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS? (target arch,ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}) this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA

Re: Cross compiling for Cortex A9

Karel, Not solved yet, but I did not notice the target problem. It is obvious once pointed out. I’ll try to fix that and try again and report back. Thanks, Mike On Jul 11, 2014, at 4:35 AM, Karel Gardas karel.gar...@centrum.cz wrote: I'm not sure if this is already solved, but if you

Re: Cross compiling for Cortex A9

Karel, I have failed to figure out how to make this happen: (target arch, ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”) I have added poky to the list of vendors in aclocal.m4 then configured like this: /configure --target=arm-poky-linux-gnueabi

Re: Cross compiling for Cortex A9

to the console. But putStrLn fails, and program enters an infinite loop. Hmmm, very peculiar. I would probably begin by compiling with `-auto-all -caf-all -prof` and run the resulting executable with `+RTS -xc`. SIGINT the process after a second or so and see what the backtrace looks like. While worth

Re: Cross compiling for Cortex A9

hrmmm, i seem to recall it being said that you need to use the GOLD linker on ARM. (i think some of this is detailed in http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html ) ,(ld command,arm-poky-linux-gnueabi-ld) is that GOLD? On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones

Cross compiling for Cortex A9

I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the

Re: Cross compiling for Cortex A9

could you share the output of ghc --info? On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones m...@proclivis.com wrote: I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. The cross compiler produces

Re: Cross compiling for Cortex A9

I am pasting both the info from the HOST and TARGET compilers: HOST [(Project name,The Glorious Glasgow Haskell Compilation System) ,(GCC extra via C opts, -fwrapv) ,(C compiler command,/usr/bin/gcc) ,(C compiler flags, -fno-stack-protector -Wl,--hash-size=31

Re: [Haskell-cafe] Compiling arbitrary Haskell code

? * #includes — I presume there's some security risk with including any old file? * FFI -- speaks for itself I'm interested in the idea of compiling Haskell code on lpaste.org, for core, rule firings, maybe even Th expansion, etc. When sandboxing code that I'm running, it's really easy if I

[Haskell-cafe] Compiling arbitrary Haskell code

risk with including any old file? * FFI -- speaks for itself I'm interested in the idea of compiling Haskell code on lpaste.org, for core, rule firings, maybe even Th expansion, etc. When sandboxing code that I'm running, it's really easy if I whitelist what code is available (parsing with HSE

Re: [Haskell-cafe] Compiling arbitrary Haskell code

. I think the list you have above is a good start, but wouldn't be complete for lambdabot. I'm interested in the idea of compiling Haskell code on lpaste.org, for core, rule firings, maybe even Th expansion, etc. When sandboxing code that I'm running, it's really easy if I whitelist what code

Re: [Haskell-cafe] Compiling arbitrary Haskell code

? * #includes — I presume there's some security risk with including any old file? * FFI -- speaks for itself I'm interested in the idea of compiling Haskell code on lpaste.org, for core, rule firings, maybe even Th expansion, etc. When sandboxing code that I'm running, it's really easy if I whitelist

Re: [Haskell-cafe] Compiling arbitrary Haskell code

be dangerous: * TemplateHaskell/QuasiQuotes -- obviously * Are rules safe? * #includes — I presume there's some security risk with including any old file? * FFI -- speaks for itself I'm interested in the idea of compiling Haskell code on lpaste.org, for core, rule firings, maybe even Th

Re: [Haskell-cafe] Compiling arbitrary Haskell code

communicate with the rest of the world in some limited way) than the other way around. Yeah, the impression I'm getting is that compiling pretty much anything other than simple expressions (a la lambdabot) is that all bets are off. ___ Haskell-Cafe mailing list

Re: [Haskell-cafe] Tasty not compiling

* Thiago Negri evoh...@gmail.com [2013-08-29 22:27:47-0300] I can't install tasty with cabal. Anyone with the same issue or a fix? $ cabal install tasty ... Test\Tasty\Core.hs:147:11: Not in scope: `witness' You probably have a too old version of 'tagged'. I'll add the lower version bound

[Haskell-cafe] Tasty not compiling

I can't install tasty with cabal. Anyone with the same issue or a fix? $ cabal install tasty ... Test\Tasty\Core.hs:147:11: Not in scope: `witness' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org

Re: [Haskell-cafe] Compiling stringable with GHC 7.0.4

stringable-0.1.1... [1 of 1] Compiling Data.Stringable ( Data/Stringable.hs, dist/build/Data/Stringable.o ) Data/Stringable.hs:54:10: Illegal instance declaration for `Stringable String' (All instance types must be of the form (T t1 ... tn) where T is not a synonym

[Haskell-cafe] Compiling haskell-platform-2013.2.0.0 fails

Hello, I'm attempting to compile haskell-platform on an Arch Linux system. It fails very soon after invoking 'make': Configuring HUnit-1.2.5.2... Setup: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it

Cross-compiling GHC: ghc-cabal: /tmp/30869.o: does not exist

I'm trying to cross-compile GHC 7.6.3; 'make' fails with the mentioned error. How can I debug this issue? I used Guix [1] to build a cross-compiler and related packages: # ./pre-inst-env guix build -K gcc-cross-mips64el-linux-gnu After that I downloaded GHC 7.6.3: # wget

[Haskell-cafe] Error compiling transformers-base-0.4.1 (debian 64 bits, ghc-7.4.2)

dependencies... Downloading transformers-base-0.4.1... Configuring transformers-base-0.4.1... Preprocessing library transformers-base-0.4.1... Building transformers-base-0.4.1... [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, dist/build/Control/Monad/Base.o ) src/Control/Monad

Re: [Haskell-cafe] Error compiling transformers-base-0.4.1 (debian 64 bits, ghc-7.4.2)

transformers-base-0.4.1... Preprocessing library transformers-base-0.4.1... Building transformers-base-0.4.1... [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, dist/build/Control/Monad/Base.o ) src/Control/Monad/Base.hs:63:10: Duplicate instance declarations: instance

[Haskell-cafe] Fwd: Error compiling transformers-base-0.4.1 (debian 64 bits, ghc-7.4.2)

J-C cabal install transformers-base Resolving dependencies... Downloading transformers-base-0.4.1... Configuring transformers-base-0.4.1... Preprocessing library transformers-base-0.4.1... Building transformers-base-0.4.1... [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs

[Haskell-cafe] Fwd: Error compiling transformers-base-0.4.1 (debian 64 bits, ghc-7.4.2)

-- Forwarded message -- From: jean-christophe mincke jeanchristophe.min...@gmail.com Date: Thu, May 9, 2013 at 7:08 PM Subject: Fwd: [Haskell-cafe] Error compiling transformers-base-0.4.1 (debian 64 bits, ghc-7.4.2) To: haskell-cafe@haskell.org haskell-cafe@haskell.org Thank you

Re: Libffi errors while cross-compiling GHC 7.6.2 (Stage 1)

Is /usr/bin/gcc a MIPS cross-compiler? If not, how do you expect it to work? Right, I wasn't using a cross-compiler. That's the problem. I haven't succeeded in cross-building yet. I'm using a distro with a non-common directory structure and I still have to figure out how to specify both

Libffi errors while cross-compiling GHC 7.6.2 (Stage 1)

I'd like to cross-build GHC 7.6.2. I got stuck when I was trying to build a Stage 1 compiler [1]. Here's a bug report: [2,3]. I'm not sure that it's a bug; maybe I misunderstood the process. Could anyone advise? I have no experience with C. Though, I'll try to help out. [1]

[Haskell-cafe] Mac os x (Intel, 10.6.8) problem compiling yesod-core-1.1.7.1

Hello GHC version : 7.4.2 When I do a cabal-dev instal yesod-core, I get the following error: Loading package blaze-builder-conduit-0.5.0.3 ... linking ... done. Loading package hashable-1.2.0.5 ... linking ... ghc: lookupSymbol failed in resolveImports

Re: [Haskell-cafe] Mac os x (Intel, 10.6.8) problem compiling yesod-core-1.1.7.1

Adding Bryan, who wrote this code. On Mon, Jan 28, 2013 at 1:23 AM, jean-christophe mincke jeanchristophe.min...@gmail.com wrote: Hello GHC version : 7.4.2 When I do a cabal-dev instal yesod-core, I get the following error: Loading package blaze-builder-conduit-0.5.0.3 ... linking ...

[GHC] #7554: Define __SSE__ when compiling with -msse

#7554: Define __SSE__ when compiling with -msse -+-- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example.

#7521: Simplifier ticks exhausted when compiling Accelerate example. -+-- Reporter: eamsden | Owner: Type: bug | Status: new Priority

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone

[GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example.

#7521: Simplifier ticks exhausted when compiling Accelerate example. ---+ Reporter: eamsden | Owner: Type: bug | Status: new Priority: normal

[Haskell-cafe] OpenAL - compiling problem

Dear Haskell Cafe, I tried installing the haskell openal library via cabal install openal I get the following error: ... [ 7 of 30] Compiling Sound.OpenAL.ALC.QueryUtils ( Sound/OpenAL/ALC/QueryUtils.hs, dist/build/Sound/OpenAL/ALC/QueryUtils.o ) Sound/OpenAL/ALC/QueryUtils.hs:66:1

Re: [Haskell-cafe] OpenAL - compiling problem

Hi Gary Which version of GHC are you using? My suspicion is that ALCdevice might be a newtype falling foul of recent changes to GHC... v7.4.1: GHC now requires, as per the standard, that if a newtype is used in an FFI declaration, then the constructor for that type must be in scope. For now you

Re: [Haskell-cafe] OpenAL - compiling problem

On 11/28/2012 07:01 PM, Stephen Tetley wrote: Hi Gary Which version of GHC are you using? My suspicion is that ALCdevice might be a newtype falling foul of recent changes to GHC... v7.4.1: GHC now requires, as per the standard, that if a newtype is used in an FFI declaration, then the

Re: [Haskell-cafe] OpenAL - compiling problem

I think OpenAL is now unmaintained. You could try to find AndrewMiller who updated the last version, otherwise you might have to patch it yourself or ask a developer of a dependent package if they would consider pushing another unmaintained release to Hackage.

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone

[Haskell-cafe] GHC 7.4.1 hangs and memory usage shoots ups to 100% when compiling with -O2

I'm facing this problem only when I compiled the code using -O2 Flag. I tried the following, * Compiled with -O1 Flag (7.4.1), It compiled fine * Compiled with ghc-7.0.4 with -O2, it's getting compiled successfully but with the Warning, SpecConstr Function `$wa{v s27vx} [lid]' has one

Re: [GHC] #3103: Compiling base with cabal fails.

#3103: Compiling base with cabal fails. -+-- Reporter: Lemmih| Owner: Type: bug | Status: new Priority: high | Milestone

Re: [GHC] #7392: the impossible happened when compiling Types.Substitutions

#7392: the impossible happened when compiling Types.Substitutions -+-- Reporter: martindemello | Owner: Type: bug | Status: new Priority

Re: [GHC] #7392: the impossible happened when compiling Types.Substitutions

#7392: the impossible happened when compiling Types.Substitutions -+-- Reporter: martindemello | Owner: Type: bug | Status: closed Priority

Re: [GHC] #5550: GHC infinite loop when compiling vector

#5550: GHC infinite loop when compiling vector -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: low

[Haskell-cafe] Compiling with hsc2hs and -Wextra

] MyHsc.hsc:16:27: error: unused parameter ‘argv’ [-Werror=unused-parameter] cc1: all warnings being treated as errors compiling dist/build/MyHsc_hsc_make.c failed (exit code 1) I would really like to compile my code with -Wextra -Werror though. Can't we just (void) argc; (void) argv

Re: [GHC] #7392: the impossible happened when compiling Types.Substitutions

#7392: the impossible happened when compiling Types.Substitutions -+-- Reporter: martindemello | Owner: Type: bug | Status: new Priority

[GHC] #7392: the impossible happened when compiling Types.Substitutions

#7392: the impossible happened when compiling Types.Substitutions +--- Reporter: martindemello | Owner: Type: bug | Status: new Priority: normal

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone

Re: GHC compiling shared library linking problem

On 17/10/2012 08:43, Richard Zetterberg wrote: I have two parts of my application; one which builds a cli application which uses my module and one which builds a shared library which uses the same module. I have no problems compiling my cli application. And if I try to compile the shared library

Re: GHC compiling shared library linking problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello and thank you for the reply Yes! It seems the details from my first mail (10/15/12 3:25 PM) fell out. Here is the relevant parts from that mail: The problem I have is that I get a linker error when compiling a shared library with GHC

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal| Milestone

Re: GHC compiling shared library linking problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Thank you for the response! I have two parts of my application; one which builds a cli application which uses my module and one which builds a shared library which uses the same module. I have no problems compiling my cli application. And if I

GHC compiling shared library linking problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello This is the first time I'm mailing to this list, so I hope I have come to the right place. The problem I have is that I get a linker error when compiling a shared library with GHC. This problem occurred after I updated GHC from 7.0.3 to 7.4.1

Re: GHC compiling shared library linking problem

Hello Richard, it sounds like you're using a ghc build that doesn't have the -dyn versions of the builtin libraries, do you have the same problem when doing a shared build without the foreign call ? On Mon, Oct 15, 2012 at 9:25 AM, Richard Zetterberg richard.zetterb...@googlemail.com wrote:

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal| Milestone

[GHC] #7322: The 'impossible happened' compiling with -fext-core

#7322: The 'impossible happened' compiling with -fext-core --+- Reporter: ydewit| Owner: Type: bug | Status: new Priority: normal

Re: [GHC] #7322: The 'impossible happened' compiling with -fext-core

#7322: The 'impossible happened' compiling with -fext-core -+-- Reporter: ydewit|Owner: Type: bug | Status: closed Priority: normal

[GHC] #7315: Link error while compiling executables

#7315: Link error while compiling executables --+- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal

Re: [GHC] #7315: Link error while compiling executables

#7315: Link error while compiling executables -+-- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal

Re: [GHC] #7315: Link error while compiling executables

#7315: Link error while compiling executables ---+ Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal

[GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7258: Compiling DynFlags is jolly slow

#7258: Compiling DynFlags is jolly slow -+-- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal| Milestone

Re: [GHC] #7235: panic! when compiling happstack-server-7.0.4

#7235: panic! when compiling happstack-server-7.0.4 +--- Reporter: guest | Owner: Type: bug| Status: closed Priority

Re: [GHC] #7235: panic! when compiling happstack-server-7.0.4

#7235: panic! when compiling happstack-server-7.0.4 +--- Reporter: guest | Owner: Type: bug| Status: closed Priority

[GHC] #7235: panic! when compiling happstack-server-7.0.4

#7235: panic! when compiling happstack-server-7.0.4 ---+ Reporter: guest | Owner: Type: bug| Status: new Priority: normal

Re: [Haskell-cafe] Compiling a haskell project as a shared library and loading it in C/C++

On 09/01/2012 12:13 AM, Farid Neshat wrote: So I'm trying to follow [this blog][1]. So I tried the code, couldn't compile the haskell part, probably due to the fact the guide uses version 6, but I have version 7 of ghc. By changing the paramaters I could compile it with the following: ghc

[Haskell-cafe] Compiling a haskell project as a shared library and loading it in C/C++

to the shared library but adding -L/usr/lib/ghc/ didn't really help. I searched a lot, but couldn't find anymore example that somebody have done this. [Here's also some docs][2] for compiling shared libraries: [1]: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell [2]: http

Re: [Haskell-cafe] Compiling Haskell targetting different OS/arch

ARM guys use native ghc to build arm binaries 2012/8/24 Taylor Hedberg t...@tmh.cc: Thiago Negri, Fri 2012-08-24 @ 13:27:32-0300: Is it possible to compile Haskell code targetting a OS/arch that differs from the one where the compiler (GHC) is running? No, GHC doesn't currently support

[Haskell-cafe] Compiling Haskell targetting different OS/arch

Is it possible to compile Haskell code targetting a OS/arch that differs from the one where the compiler (GHC) is running? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiling Haskell targetting different OS/arch

Thiago Negri, Fri 2012-08-24 @ 13:27:32-0300: Is it possible to compile Haskell code targetting a OS/arch that differs from the one where the compiler (GHC) is running? No, GHC doesn't currently support cross-compilation. signature.asc Description: Digital signature

Re: [GHC] #7110: Stack overflow when compiling with optimizations

#7110: Stack overflow when compiling with optimizations ---+ Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal

[GHC] #7110: Stack overflow when compiling with optimizations

#7110: Stack overflow when compiling with optimizations --+- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal

  1   2   3   4   5   6   7   8   9   10   >