Windows build problems

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows build problems

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?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Windows build problems

Bill Tutt
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Windows build problems

Daniel Fischer
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Windows build problems

Bill Tutt
On Thu, Sep 15, 2011 at 6:00 PM, Daniel Fischer
<[hidden email]> wrote:
>>
>> 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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Windows build problems

Bill Tutt
On Thu, Sep 15, 2011 at 9:01 PM, Bill Tutt <[hidden email]> wrote:
>
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Windows build problems

scooter.phd@gmail.com
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 <[hidden email]>
Sender: [hidden email]
Date: Thu, 15 Sep 2011 21:22:34
To: <[hidden email]>
Subject: Re: Windows build problems

On Thu, Sep 15, 2011 at 9:01 PM, Bill Tutt <[hidden email]> wrote:
>
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: Windows build problems

Simon Peyton Jones
In reply to this post by Bill Tutt
| > 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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Windows build problems

Bill Tutt
I'm thinking that I want to modify libraries/base/configure.ac to
implement this pseudo-code:

<Psedo code: if $WINDOWS <> "YES" or --with-iconv-libraries was specified then>:
FP_SEARCH_LIBS_PROTO(iconv,  <...>)
<else skip iconv checking with message>

That way the GHC binary on Windows doesn't grow a dependency on the
mingw iconv goo that would require followup changes in the rest of the
GHC source.
I have no desire to add mingw iconv support to GHC.

The above approach wouldn't necessarily need the
--with-iconv-libraries alternative, but it seems like the autoconfy
like thing to do. Thoughts?

I can try to come up with something, but my sh/autoconf foo is very
very low. I'd be glad to test a change if somebody could translate my
pseudo code for me that'd be awesome.

I'm not quite sure how to check the --with-iconv-libraries bit via
autoconf just yet.

Thanks,
Bill

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users