Re: Building on windows
I believe those instructions are only for setting up MSYS2. You are still expected to have `ghc` on your path. On Sun, Oct 21, 2018 at 6:48 PM Yotam Ohad wrote: > > This is it:https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > Step one, method B > > On Sun, Oct 21, 2018 at 8:46 PM Matthew Pickering > wrote: >> >> Which guide are you referring to? I don't know of any which say to use stack. >> On Sun, Oct 21, 2018 at 6:44 PM Yotam Ohad wrote: >> > >> > Hi, >> > >> > I've tried to build ghc on windows 10 with msys. I've installed it with >> > stack as said on the guide. In the msys shell, after updating and >> > installing everything I've tried to run `./configure >> > --enable-tarballs-autodownload` and got the following error: >> > >> > configure: loading site script /mingw64/etc/config.site >> > checking for gfind... no >> > checking for find... /usr/bin/find >> > checking for sort... /usr/bin/sort >> > checking for GHC version date... inferred 8.7.20181017 >> > checking for GHC Git commit id... inferred >> > 46f2906d1c6e1fb732a90882487479a2ebf19ca1 >> > checking for ghc... no >> > configure: error: GHC is required. >> > >> > I have the haskell platform installed (8.4.3), yet it can't find GHC and >> > I'm not sure if I missed something from the guide >> > >> > Yotam >> > ___ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building on windows
This is it: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Step one, method B On Sun, Oct 21, 2018 at 8:46 PM Matthew Pickering < matthewtpicker...@gmail.com> wrote: > Which guide are you referring to? I don't know of any which say to use > stack. > On Sun, Oct 21, 2018 at 6:44 PM Yotam Ohad wrote: > > > > Hi, > > > > I've tried to build ghc on windows 10 with msys. I've installed it with > stack as said on the guide. In the msys shell, after updating and > installing everything I've tried to run `./configure > --enable-tarballs-autodownload` and got the following error: > > > > configure: loading site script /mingw64/etc/config.site > > checking for gfind... no > > checking for find... /usr/bin/find > > checking for sort... /usr/bin/sort > > checking for GHC version date... inferred 8.7.20181017 > > checking for GHC Git commit id... inferred > 46f2906d1c6e1fb732a90882487479a2ebf19ca1 > > checking for ghc... no > > configure: error: GHC is required. > > > > I have the haskell platform installed (8.4.3), yet it can't find GHC and > I'm not sure if I missed something from the guide > > > > Yotam > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building on windows
Which guide are you referring to? I don't know of any which say to use stack. On Sun, Oct 21, 2018 at 6:44 PM Yotam Ohad wrote: > > Hi, > > I've tried to build ghc on windows 10 with msys. I've installed it with stack > as said on the guide. In the msys shell, after updating and installing > everything I've tried to run `./configure --enable-tarballs-autodownload` and > got the following error: > > configure: loading site script /mingw64/etc/config.site > checking for gfind... no > checking for find... /usr/bin/find > checking for sort... /usr/bin/sort > checking for GHC version date... inferred 8.7.20181017 > checking for GHC Git commit id... inferred > 46f2906d1c6e1fb732a90882487479a2ebf19ca1 > checking for ghc... no > configure: error: GHC is required. > > I have the haskell platform installed (8.4.3), yet it can't find GHC and I'm > not sure if I missed something from the guide > > Yotam > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building on windows
Hi, I've tried to build ghc on windows 10 with msys. I've installed it with stack as said on the guide. In the msys shell, after updating and installing everything I've tried to run `./configure --enable-tarballs-autodownload` and got the following error: configure: loading site script /mingw64/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.7.20181017 checking for GHC Git commit id... inferred 46f2906d1c6e1fb732a90882487479a2ebf19ca1 checking for ghc... no configure: error: GHC is required. I have the haskell platform installed (8.4.3), yet it can't find GHC and I'm not sure if I missed something from the guide Yotam ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building on Windows
That may have been it, thanks. On Fri, Aug 21, 2015 at 9:52 AM, Tamar Christina loneti...@gmail.com wrote: Hmm no that doesn't seem familiar to me. It looks like some Windows style paths are being passed around but don't know why.. Are you running the non-emulating shells? E.g. The MinGW-w64 Win64 Shell bat? -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 8:27 To: Tamar Christina loneti...@gmail.com Cc: ghc-devs@haskell.org Subject: Re: Building on Windows That worked, and got me much farther. If you don't mind one more newb question, I'm now seeing the following. Any thoughts? ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all /usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe inplace/bin/hp2ps.exe cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt inplace/bin/ghc-stage1.exe -o driver/ghci/dist/build/tmp/ghci.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -odir driver/ghci/dist/build -hidir driver/ghci/dist/build -stubdir driver/ghci/dist/build-static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -no-auto-link-packages -no-hs-main driver/ghci/dist/build/ghci.o driver/ghci/dist/build/../utils/cwrapper.o driver/ghci/dist/build/../utils/getLocation.o driver/ghci/ghci.res Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. gcc.exe: error: driverghcidistbuildghci.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or directory gcc.exe: error: driverghcighci.res: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory driver/ghci/ghc.mk:39: recipe for target 'driver/ghci/dist/build/tmp/ghci.exe' failed make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman mich...@snoyman.com wrote: Awesome, thanks for the quick response Tamar. Cloning now. On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com wrote: Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 7:06 To: ghc-devs@haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building on Windows
My original patch https://ghc.haskell.org/trac/ghc/attachment/ticket/10777/cabal-rsp.patch contains 'normslash' function. It seems, Michael have overlooked this. GNU tools wait response files containing forward slashes in paths. On 21.08.2015 9:52, Tamar Christina wrote: Hmm no that doesn't seem familiar to me. It looks like some Windows style paths are being passed around but don't know why.. Are you running the non-emulating shells? E.g. The MinGW-w64 Win64 Shell bat? From: Michael Snoyman mailto:mich...@snoyman.com Sent: 8/21/2015 8:27 To: Tamar Christina mailto:loneti...@gmail.com Cc: ghc-devs@haskell.org mailto:ghc-devs@haskell.org Subject: Re: Building on Windows That worked, and got me much farther. If you don't mind one more newb question, I'm now seeing the following. Any thoughts? ===--- building final phase make -r --no-print-directory -f ghc.mk http://ghc.mk phase=final all /usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe inplace/bin/hp2ps.exe cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt inplace/bin/ghc-stage1.exe -o driver/ghci/dist/build/tmp/ghci.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -odir driver/ghci/dist/build -hidir driver/ghci/dist/build -stubdir driver/ghci/dist/build -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -no-auto-link-packages -no-hs-main driver/ghci/dist/build/ghci.o driver/ghci/dist/build/../utils/cwrapper.o driver/ghci/dist/build/../utils/getLocation.o driver/ghci/ghci.res Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. gcc.exe: error: driverghcidistbuildghci.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or directory gcc.exe: error: driverghcighci.res: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory driver/ghci/ghc.mk:39 http://ghc.mk:39: recipe for target 'driver/ghci/dist/build/tmp/ghci.exe' failed make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman mich...@snoyman.com mailto:mich...@snoyman.com wrote: Awesome, thanks for the quick response Tamar. Cloning now. On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com mailto:loneti...@gmail.com wrote: Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git http://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar From: Michael Snoyman mailto:mich...@snoyman.com Sent: 8/21/2015 7:06 To: ghc-devs@haskell.org mailto:ghc-devs@haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building on Windows
That worked, and got me much farther. If you don't mind one more newb question, I'm now seeing the following. Any thoughts? ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all /usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe inplace/bin/hp2ps.exe cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt inplace/bin/ghc-stage1.exe -o driver/ghci/dist/build/tmp/ghci.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -odir driver/ghci/dist/build -hidir driver/ghci/dist/build -stubdir driver/ghci/dist/build-static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -no-auto-link-packages -no-hs-main driver/ghci/dist/build/ghci.o driver/ghci/dist/build/../utils/cwrapper.o driver/ghci/dist/build/../utils/getLocation.o driver/ghci/ghci.res Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. gcc.exe: error: driverghcidistbuildghci.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or directory gcc.exe: error: driverghcighci.res: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory driver/ghci/ghc.mk:39: recipe for target 'driver/ghci/dist/build/tmp/ghci.exe' failed make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman mich...@snoyman.com wrote: Awesome, thanks for the quick response Tamar. Cloning now. On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com wrote: Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 7:06 To: ghc-devs@haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Building on Windows
Hmm no that doesn't seem familiar to me. It looks like some Windows style paths are being passed around but don't know why.. Are you running the non-emulating shells? E.g. The MinGW-w64 Win64 Shell bat? -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 8:27 To: Tamar Christina loneti...@gmail.com Cc: ghc-devs@haskell.org Subject: Re: Building on Windows That worked, and got me much farther. If you don't mind one more newb question, I'm now seeing the following. Any thoughts? ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all /usr/bin/install -c -m 755 utils/hp2ps/dist/build/tmp/hp2ps.exe inplace/bin/hp2ps.exe cp driver/ghc-usage.txt inplace/lib/ghc-usage.txt cp driver/ghci-usage.txt inplace/lib/ghci-usage.txt inplace/bin/ghc-stage1.exe -o driver/ghci/dist/build/tmp/ghci.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -odir driver/ghci/dist/build -hidir driver/ghci/dist/build -stubdir driver/ghci/dist/build-static -H32m -O -i -idriver/ghci/. -idriver/ghci/dist/build -idriver/ghci/dist/build/autogen -Idriver/ghci/dist/build -Idriver/ghci/dist/build/autogen -no-user-package-db -rtsopts -no-auto-link-packages -no-hs-main driver/ghci/dist/build/ghci.o driver/ghci/dist/build/../utils/cwrapper.o driver/ghci/dist/build/../utils/getLocation.o driver/ghci/ghci.res Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. gcc.exe: error: driverghcidistbuildghci.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilscwrapper.o: No such file or directory gcc.exe: error: driverghcidistbuild..utilsgetLocation.o: No such file or directory gcc.exe: error: driverghcighci.res: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_4.o: No such file or directory gcc.exe: error: C:msys64-2tmpghc6528_0ghc_2.o: No such file or directory driver/ghci/ghc.mk:39: recipe for target 'driver/ghci/dist/build/tmp/ghci.exe' failed make[1]: *** [driver/ghci/dist/build/tmp/ghci.exe] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 On Fri, Aug 21, 2015 at 8:18 AM, Michael Snoyman mich...@snoyman.com wrote: Awesome, thanks for the quick response Tamar. Cloning now. On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com wrote: Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 7:06 To: ghc-devs@haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Building on Windows
Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 7:06 To: ghc-devs@haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building on Windows
I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building on Windows
Awesome, thanks for the quick response Tamar. Cloning now. On Fri, Aug 21, 2015 at 8:16 AM, Tamar Christina loneti...@gmail.com wrote: Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar -- From: Michael Snoyman mich...@snoyman.com Sent: 8/21/2015 7:06 To: ghc-devs@haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building on Windows
Hi, I just successfully built GHC on Windows. Last time I tried (5 years ago) it took days. This time, it took hours, plus a bit of waiting for a Windows specific breakage to be fixed. I made a log of what happened, what confused me, what wasn't clear etc - hopefully these provide suggestions for improving the wiki (if my thoughts are actually correct). The worst aspect is that the Windows wiki page has 6 sets of instructions, with no obvious way to pick the right one - everything else was pretty minor. Thanks, Neil My first step was to Google build ghc on windows, which took me to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows The instructions are current for GHC 7.6 - so they are not current. Other documentation for Windows includes: - here are 5 alternate links, any of which may be better/worse than this one. I have no way to tell. As a piece of documentation, giving the uninformed user 6 options with no sensible way to make a decision is awful. Simon PJ had said MSYS2 works well, so I clicked that one. Even though it appears to be the wrong one according to the wiki. Is it the correct one? If so, replace the Windows page with it. If not, perhaps indicate which one is. It should get you running in ~5 minutes, modulo download speeds. - nice! It's a long way from being true, since you also need to include extraction times and build times (which on my machine far outweight download times). There were also enough hiccups that it took me about an hour of clicking/typing, excluding the Windows specific bug I ran into. If I have 64bit OS, should I pick 64bit Windows? Or only if I want to develop 64bit Windows, which isn't the default? Fortunately my machine is old enough to be 32 bits so I didn't have the difficult question. It's far easier to edit the PATH file manually with $ cygpath -w ~, which returns C:\msys32\home\Neil, than to echo stuff to it. In particular, if you echo anything wrong, you need to edit it anyway. Do not install python, python2 or gcc! - it's not entirely clear how to achieve that. It installed gcc-libs, is that a problem? I'd have liked a better check step, e.g. run gcc --version, ghc --version and exactly what I should expect, what indicates a problem etc. e.g what should i be on the lookout for to say Python doesn't build. I followed the step to upgrade my system, but it failed: :: Starting full system upgrade... :: Replace msys2-base with msys/filesystem? [Y/n] (55/55) checking for file conflicts[##] 100% error: failed to commit transaction (conflicting files) bash-completion: /etc/profile.d/bash_completion.sh exists in filesystem coreutils: /etc/DIR_COLORS exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/java/cacerts exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists in filesystem filesystem: /etc/profile.d/lang.sh exists in filesystem filesystem: /etc/profile.d/tzset.sh exists in filesystem filesystem: /etc/skel/.inputrc exists in filesystem filesystem: /mingw32_shell.bat exists in filesystem filesystem: /mingw64_shell.bat exists in filesystem filesystem: /msys2_shell.bat exists in filesystem grep: /usr/bin/egrep exists in filesystem grep: /usr/bin/fgrep exists in filesystem rebase: /autorebase.bat exists in filesystem Errors occurred, no packages were upgraded. I just ignored that, and continued, and that seemed to go OK... /ghc-7.6.3/ didn't work, I needed to go /c/ghc/ghc-7.6.3/ for the paths. Perhaps make it clear which are absolute paths, and which you have to edit. Perhaps you were hoping I'd symlink the GHC path? Any reason for the commands in the final list of commands? isn't one per line cleaner? It also lets you retry the right bit when something fails. checking for version of happy... 1.18.4 configure: error: Happy version 1.19.4 or later is required to compile GHC. Nice - this was a useful check that made it easy to fix and continue. $ make -j3 + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk 2 [main] make 6024 child_info_fork::abort: C:\msys32\bin\msys-unistring-2.dll: Loaded to different address: parent(0x25) != child(0x7C) make: fork: Resource temporarily unavailable This error repeated. On a hunch I ran autorebase.bat from msys32, and restarted my shell, then it worked - I have no idea which fixed it. inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O-this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries
Re: Release building for Windows
Seems to me that given the state of affairs, it is best to just leave it as it is this round: That is GHC is built split-obj, but the HP libs on Windows are not. In general, split-obj only makes executables smaller at the expense of link time and memory. It is a trade-off, and I'd make the call for faster link, and now uncertainty for now. So, unless there is objection, I'd call RC4 final for Windows. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Release building for Windows
Hi, On 4 August 2014 14:52, Sven Panne svenpa...@gmail.com wrote: Do you have an URL for this FAQ? I can't find it, and I can't remember what's wrong with --enable-split-objs. :-( What is the impact for people using large libraries (like OpenGL/OpenGLRaw/...) where you often use only a small part? Will you get a huge executable then? IIRC that's at least the case for Linux. https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ One of the problems is that split-objs is extremely slow, especially on Windows. I had to disable split-objs for OpenGL-related libraries when building the HP installer in the past because of this. Randy also said that libraries built with split-objs don't work well in ghci on Windows x64. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Release building for Windows
2014-08-04 14:59 GMT+02:00 Mikhail Glushenkov the.dead.shall.r...@gmail.com: https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ Hmmm, this isn't very specific, it just says that there are probably bugs, but that's true for almost all code. :-) Are there any concrete issues with --enable-split-objs? One of the problems is that split-objs is extremely slow, especially on Windows. I had to disable split-objs for OpenGL-related libraries when building the HP installer in the past because of this. I think it's perfectly fine if the the compilation of the library itself takes ages if it pays off later: You compile the library once, but link against it multiple times. Or do the link times against e.g. OpenGL stuff suffer? My point is: Do we make the right trade-off here? A quick search brought up e.g. https://github.com/gentoo-haskell/gentoo-haskell/issues/169 which seems to be a request to split everything. Randy also said that libraries built with split-objs don't work well in ghci on Windows x64. Is there an issue for this? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Release building for Windows
Mark, Randy, Sorry for the delayed reply! On Fri, Aug 1, 2014 at 9:49 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a member. He's cc'd so you can reply to all and include him... or I can forward as needed. From Randy: -- I am building the Haskell Platform 2014.2.0.0 on the Windows side. Your advice would be very helpful to make sure the HP 2014 for Windows is as good as possible. There were some issues I worked-around, plus some features that seem to not be available in this particular GHC (7.8.3) on the 32-bit and 64-bit Windows platforms, and I would like to confirm that HP 2014.2.0.0 will be shipping something sensible and as expected for the Windows environment, noting things which are supported on other environments but not on Windows. * GHC 7.8.3 on Windows does not support building Haskell into shared libraries, (GHC ticket #8228) so all packages in HP 2014.2.0.0 for Windows have been built without --enable-shared That's correct. * GHC 7.8.3 on Windows does not currently support LLVM (GHC ticket #7143) Correct. * All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ No, this shouldn't be needed. split-objs should work just fine on Windows; the FAQ was referencing the fact that *users* using split-objs in their Cabal configurations will probably get odd behavior (we don't encourage split-objs outside of the packages GHC ships). Sometimes bugs arise but these generally aren't high priority for arbitrary user code. (It will also hurt users since it will dramatically increase link time - it should only be used for GHC libraries!) If you have issues here, please let me know; it's a bug. * Extra python, etc. bits included in the GHC 7.8.3 bindist for 64-bit Windows (GHC issue #9014) are not installed with Windows HP 2014.2.0.0. Is eliding them from the HP 2014.2.0.0 64-bit Windows installation safe and correct (i.e., are they truely not required)? H, that seems like a total oversight on my part! Yes, deleting them should be fine. Upon review, I think they're just artifacts of our 64 bit MinGW distribution. * Missing src/html in GHC packages were worked around by replacing the entire GHC package doc tree of html files with the contents of the Standard Libraries tarball (but not for the two packages which are not built for Windows, terminfo and unix). Is this valid to do? Any issues might arise? * ref: http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 This should be just fine. Thanks for any advice on these. I do want to make the Windows HP 2014.2.0.0 be as good as it can be. Randy ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Release building for Windows
On Mon, Aug 4, 2014 at 8:50 AM, Sven Panne svenpa...@gmail.com wrote: 2014-08-04 14:59 GMT+02:00 Mikhail Glushenkov the.dead.shall.r...@gmail.com: https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ Hmmm, this isn't very specific, it just says that there are probably bugs, but that's true for almost all code. :-) Are there any concrete issues with --enable-split-objs? Sorry for the confusion; I just meant you *should not* enable split-objs in your cabal configuration - GHC uses it for its libraries, but in general users don't want it for arbitrary code (bugs, huge linking time and memory usage, etc). One of the problems is that split-objs is extremely slow, especially on Windows. I had to disable split-objs for OpenGL-related libraries when building the HP installer in the past because of this. I think it's perfectly fine if the the compilation of the library itself takes ages if it pays off later: You compile the library once, but link against it multiple times. Or do the link times against e.g. OpenGL stuff suffer? My point is: Do we make the right trade-off here? A quick search brought up e.g. https://github.com/gentoo-haskell/gentoo-haskell/issues/169 which seems to be a request to split everything. Randy also said that libraries built with split-objs don't work well in ghci on Windows x64. Is there an issue for this? Yes, there should be a bug filed for this if there isn't one already. But problems with the GHC build itself are really more of the priority than arbitrary user facing code. Still, a ticket would be good. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Release building for Windows
Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a member. He's cc'd so you can reply to all and include him... or I can forward as needed. From Randy: -- I am building the Haskell Platform 2014.2.0.0 on the Windows side. Your advice would be very helpful to make sure the HP 2014 for Windows is as good as possible. There were some issues I worked-around, plus some features that seem to not be available in this particular GHC (7.8.3) on the 32-bit and 64-bit Windows platforms, and I would like to confirm that HP 2014.2.0.0 will be shipping something sensible and as expected for the Windows environment, noting things which are supported on other environments but not on Windows. * GHC 7.8.3 on Windows does not support building Haskell into shared libraries, (GHC ticket #8228) so all packages in HP 2014.2.0.0 for Windows have been built without --enable-shared * GHC 7.8.3 on Windows does not currently support LLVM (GHC ticket #7143) * All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ * Extra python, etc. bits included in the GHC 7.8.3 bindist for 64-bit Windows (GHC issue #9014) are not installed with Windows HP 2014.2.0.0. Is eliding them from the HP 2014.2.0.0 64-bit Windows installation safe and correct (i.e., are they truely not required)? * Missing src/html in GHC packages were worked around by replacing the entire GHC package doc tree of html files with the contents of the Standard Libraries tarball (but not for the two packages which are not built for Windows, terminfo and unix). Is this valid to do? Any issues might arise? * ref: http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 Thanks for any advice on these. I do want to make the Windows HP 2014.2.0.0 be as good as it can be. Randy ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building on Windows with msys
Nice catch! On 28/08/13 09:08, Simon Peyton-Jones wrote: Friends My Windows build (new laptop) got stuck again, but this time I managed to work out what is going on. This email is just to record the issue; I’ll add something to the wiki. *tl;dr:* a MSYS build will fail in a deeply strange way if your MSYS bin directory doesn’t take priority over the windows/system32 director. *Symptom*: “sh libtool” hangs indefinitely. The process manager shows an extant “cmd” and “sed”, but nothing else. libtool is a shell script that comes from a tarball, and is unpacked into libraries/integer-gmp/gmp/gmpbuild/libtool *Cause*: libtool invokes the following command line (in the function func_convert_coer_msys_to_w32: cmd /c “echo blah” and pipes the result to sed. /But MSYS mangles the command line to turn slashes into backslashes./ So the actual command line is more like cmd \c “echo blah” which does something entirely different, and indeed hangs waiting for input on stdin. *Solution*: So how did this ever work on any MSYS installation? Because ·msys/1.0/bin has a little script “cmd” which hands off to the real c:/windows/system32/cmd ·MSYS does not mangle the command-line for programs in msys/1.0/bin ·/On my old laptop, msys/1.0/bin was in my path before c:/windows/system32/. So plain “cmd” gets the script, and MSYS does not mangle the command line. The script passes arguments on unchanged to the real cmd. ·NB: c:/windows/system32 is in the “system” path, which precedes the “user” path. So no amount of fiddling with the “user” path will fix this. There are two solutions: oModify the system path oUse a .bashrc file to prepend the stuff you need This is pretty subtle stuff. Simon /Microsoft Research Limited (company number 03369488) is registered in England and Wales / /Registered office is at 21 Station Road, Cambridge, CB1 2FB/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building on windows
I fixed the ./sync-all detection (I just checked it myself, but thanks for the patch though Niklas!) Simon, I've got a working i386/windows build here, but I'll rebuild a new VM and try again and closely follow the docs and amend what's necessary. In the mean time, perhaps try with a fresh tree? On Fri, Aug 23, 2013 at 5:40 AM, Niklas Larsson metanik...@gmail.comwrote: Here is a patch for this bug. It just adds 'msys' to the $OSNAME check. Niklas 2013/8/23 Niklas Larsson metanik...@gmail.com Hi! The check for Windows in sync-all is failing (line 790). On a mingw/msys system $OSNAME contains 'msys' and not MSWin32 or Cygwin that it is checking for. Niklas 2013/8/23 Simon Peyton-Jones simo...@microsoft.com I’ve got a new Windows laptop, and have being having a torrid time getting GHC to build on it. ** ** **1. **Build falls over with checking for gcc... c:/code/HEAD/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables Turns out that an earlier error was configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4050: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created configure: Making in-tree perl tree BUT this error was not fatal, so the build went on (notwithstanding the red message above), leading to a MUCH more obscure error later. ** ** **2. **Why wasn’t ghc-tarballs there? Oh, apparently you have to say sync-all –windows get That’s really hard for a naïve user to work out. Can’t we either always get it, or work out that we are on windows? ** ** **3. **I carefully installed mingw/msys as described on http://www.mingw.org/wiki/Getting_Started I used mingw-set-inst, which launches a GUI for a package installer. All seems well. I update my path. But then Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: /mingw/share/autoco nf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_ perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) a t /c/Programme/MinGW/bin/autoreconf-2.68 line 40. BEGIN failed--compilation aborted at /c/Programme/MinGW/bin/autoreconf-2.68 line 40. After a long struggle I found that I had missed a crucial thing. With the new autoconf tools, *it’s essential that c:/mingw be mounted as /mingw*, because /mingw is hard-coded into autoconf perl scripts. http://www.mingw.org/wiki/Getting_Started does say (deep in the middle) to edit c:/mingw/msys/1.0/etc/fstab with a text editor, but that appeared to have no effect for me. Saying “mount c:/mingw /mingw” did work. I have no idea why. ** ** What is horrible is how uninformative the error message is. ** ** I guess we should update the Windows build instructions. ** ** I still don’t know if I’ve bottomed out here because I can’t find Happy/Alex in the Haskell platform. Sigh. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Building on windows
I've got a new Windows laptop, and have being having a torrid time getting GHC to build on it. 1. Build falls over with checking for gcc... c:/code/HEAD/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables Turns out that an earlier error was configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4050: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created configure: Making in-tree perl tree BUT this error was not fatal, so the build went on (notwithstanding the red message above), leading to a MUCH more obscure error later. 2. Why wasn't ghc-tarballs there? Oh, apparently you have to say sync-all -windows get That's really hard for a naïve user to work out. Can't we either always get it, or work out that we are on windows? 3. I carefully installed mingw/msys as described on http://www.mingw.org/wiki/Getting_Started I used mingw-set-inst, which launches a GUI for a package installer. All seems well. I update my path. But then Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: /mingw/share/autoco nf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_ perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) a t /c/Programme/MinGW/bin/autoreconf-2.68 line 40. BEGIN failed--compilation aborted at /c/Programme/MinGW/bin/autoreconf-2.68 line 40. After a long struggle I found that I had missed a crucial thing. With the new autoconf tools, it's essential that c:/mingw be mounted as /mingw, because /mingw is hard-coded into autoconf perl scripts. http://www.mingw.org/wiki/Getting_Started does say (deep in the middle) to edit c:/mingw/msys/1.0/etc/fstab with a text editor, but that appeared to have no effect for me. Saying mount c:/mingw /mingw did work. I have no idea why. What is horrible is how uninformative the error message is. I guess we should update the Windows build instructions. I still don't know if I've bottomed out here because I can't find Happy/Alex in the Haskell platform. Sigh. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building on windows
Additionally, if you're using the latest MinGW it ships with GCC 4.7 and fails with an error I reported and thoughtpolice replied here; http://ghc.haskell.org/trac/ghc/ticket/7056#comment:9 There's a patch that (with some hacking, namely, fixing the missing bracket) will bring GHC to build. It later faults again, though. http://lpaste.net/92097 Windows needs some love :( ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
