From Daniel Fischer:
I'm trying to set up a build/test environment on Windows.
Building ghc (sh validate) fails after a while due to flex and bison crashing. Those two come with git and even $ flex --version (or bison) crashes, so they seem truly hosed.
Do I need flex/bison at all to build ghc? It seems they're not used on linux for building ghc. So, if not, how do I configure things that the build doesn't try to use bison/flex? If yes, would installing flex and bison from gnuwin32 work?
I ran into this issue last night as well. See http://hackage.haskell.org/trac/ghc/ticket/5489 flex appears to be required from integer-gmp's ./configure for one of GMP's demo programs. (a calculator demo I think) I'm trying to see if a slightly newer msys installation process as listed in the Trac bug will take care of it. However, last night I got a stage 1 ghc seg fault while compiling some Haskell code further along in the build. I currently have a devel1 build in progress to see what I come up with next. I also ran into: http://hackage.haskell.org/trac/ghc/ticket/5488 about bootstrapping using the Windows 7.2.1 standalone bits to bootstrap ghc-HEAD. If the devel1 build doesn't give any useful symptoms to pass along I'll probably retry the build using the Haskell Platform compiler. Fyi, Bill
On Thursday 15 September 2011, 21:41:10, Bill Tutt wrote:
From Daniel Fischer:
I'm trying to set up a build/test environment on Windows.
Building ghc (sh validate) fails after a while due to flex and bison crashing. Those two come with git and even $ flex --version (or bison) crashes, so they seem truly hosed.
Do I need flex/bison at all to build ghc? It seems they're not used on linux for building ghc. So, if not, how do I configure things that the build doesn't try to use bison/flex? If yes, would installing flex and bison from gnuwin32 work?
I ran into this issue last night as well. See http://hackage.haskell.org/trac/ghc/ticket/5489
Ugh. I'd like to avoid uninstalling msys and installing something new if possible.
flex appears to be required from integer-gmp's ./configure for one of GMP's demo programs. (a calculator demo I think)
I can't find anything indicating that on linux, so it'd be probably be due to using the in-tree gmp on Windows? But the only mention of flex that seems possibly relevant is # These flags make flex 8-bit SRC_FLEX_OPTS += -8 in mk/config.mk.in, and bison is only mentioned in two word lists in libraries/bytestring/tests at all (as the animal of course). So I'm still mystified.
I'm trying to see if a slightly newer msys installation process as listed in the Trac bug will take care of it.
If you get it to work, I'd appreciate detailed (Windows is so far utterly incomprehensible to me, so they'd better be very explicit) instructions.
However, last night I got a stage 1 ghc seg fault while compiling some Haskell code further along in the build.
Perhaps compiling GHC.Debug.hs? That's where I get a stage1 segfault on linux when bootstrapping with 7.2.1, cf http://hackage.haskell.org/trac/ghc/ticket/5484 However, I'm bootstrapping with 7.0.4 (switched on Windows due to the ar location problem mentioned in #5488, that gets me to the bison/flex problem, builds fine on linux).
I currently have a devel1 build in progress to see what I come up with next.
I also ran into: http://hackage.haskell.org/trac/ghc/ticket/5488 about bootstrapping using the Windows 7.2.1 standalone bits to bootstrap ghc-HEAD. If the devel1 build doesn't give any useful symptoms to pass along I'll probably retry the build using the Haskell Platform compiler.
If your stage1 segfault is the same as mine, switching to 7.0.x should get you around it.
Fyi, Bill
Thx, Daniel
On Thu, Sep 15, 2011 at 6:00 PM, Daniel Fischer
flex appears to be required from integer-gmp's ./configure for one of GMP's demo programs. (a calculator demo I think)
I can't find anything indicating that on linux, so it'd be probably be due to using the in-tree gmp on Windows? But the only mention of flex that seems possibly relevant is
integer-gmp/gmp/gmpbuild/configure.in has AM_PROG_LEX which requires (f)lex. it also has AC_PROG_YACC which I'd guess requires yacc/bison.
I'm trying to see if a slightly newer msys installation process as listed in the Trac bug will take care of it.
If you get it to work, I'd appreciate detailed (Windows is so far utterly incomprehensible to me, so they'd better be very explicit) instructions.
I feel your pain. The Windows instructions could definately use some updating. :) I ended up getting an error during stage 2 about the iconv.dll not being findable. (I'm guessing the new msys/mingw autosmarted GHC boot/configure or cabal configure process somehow ....) ghc-stage2 was trying to build vector-0.8 and failed during Loading package base ... (due to not finding iconv.dll)
However, last night I got a stage 1 ghc seg fault while compiling some Haskell code further along in the build.
Perhaps compiling GHC.Debug.hs? That's where I get a stage1 segfault on linux when bootstrapping with 7.2.1, cf http://hackage.haskell.org/trac/ghc/ticket/5484
That sounds like it. I'll go back and look at that after I see how bad the iconv issue is to chase down. That msys install the wiki points everybody at really is ancient. :) Bill
On Thu, Sep 15, 2011 at 9:01 PM, Bill Tutt
I ended up getting an error during stage 2 about the iconv.dll not being findable. (I'm guessing the new msys/mingw autosmarted GHC boot/configure or cabal configure process somehow ....)
Yep. This is most likely the problem. -liconv wasn't found during Simon's 8/23 ghc-HEAD build on Windows: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/377/8.html cabal configure of libraries\base found a working -liconv from one of: /bin/libiconv-2.dll /msys/1.0/bin/msys-libiconv-2.dll /lib/libiconv.a /lib/libiconv.dll.a /lib/libiconv.la The in tree mingw is picking up /lib/libiconv.a but apparently libraries\base\configure doesn't require it to be a shared library. Fyi, Bill
Bill:
It might also be the case that you're seeing the same issue as ghci not finding the stdc++ library. The solution may be as simple as hacking the Makefile is nail a specific PATH to where iconv.dll is located. But, I'm not in front of a development box, so I can't be of much help.
-scooter
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Bill Tutt
I ended up getting an error during stage 2 about the iconv.dll not being findable. (I'm guessing the new msys/mingw autosmarted GHC boot/configure or cabal configure process somehow ....)
Yep. This is most likely the problem. -liconv wasn't found during Simon's 8/23 ghc-HEAD build on Windows: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/377/8.html cabal configure of libraries\base found a working -liconv from one of: /bin/libiconv-2.dll /msys/1.0/bin/msys-libiconv-2.dll /lib/libiconv.a /lib/libiconv.dll.a /lib/libiconv.la The in tree mingw is picking up /lib/libiconv.a but apparently libraries\base\configure doesn't require it to be a shared library. Fyi, Bill _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| > If you get it to work, I'd appreciate detailed (Windows is so far utterly | > incomprehensible to me, so they'd better be very explicit) instructions. | > | | I feel your pain. The Windows instructions could definately use some | updating. :) | | I ended up getting an error during stage 2 about the iconv.dll not | being findable. (I'm guessing the new msys/mingw autosmarted GHC | boot/configure or cabal configure process somehow ....) If one of you felt able to update the instructions (it's a wiki), when you've figured out what to do, that would be absolutely fantastic! Thanks Simon
I'm thinking that I want to modify libraries/base/configure.ac to
implement this pseudo-code:
participants (4)
-
B. Scott Michel -
Bill Tutt -
Daniel Fischer -
Simon Peyton-Jones