Re: A future for the Windows packaging situation.
On Wed, May 13, 2020 at 12:56 PM Hécate wrote: > As some of you may have seen from the long threads in haskell-cafe@, > countless steps of various difficulty for Windows users > (excluding power-users) need to be taken in order to have a proper > working GHC / Haskell installation on their machine. Could you (or someone) summarize these issues and steps? I remember one of the big issues was *network* and the likes (which is frankly an issue with other languages as well), but from the sound of this post, I assume there's more. > Their contract would involve the initial setup of CI tasks able to > produce MSIX packages Hopefully that wouldn't become the only way to download GHC. > Ideally we could have a GUI to install libraries easily, like many > GNU/Linux package managers offer. Sounds great, but is it reasonable? GNU/Linux package managers AFAIK don't install Haskell libraries either. > The important thing to keep in mind is that the GNU/Linux and macOS > users *cannot* hold the Windows users to the same standards in > terms of CLI usability. It's true that one-liners and scripting is harder in Cmd, but simple commands (no pipes, no flow control etc.) that are the bread and butter for developers work just fine. I sense I'm missing some context; why is this an issue? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows build broken again
On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote: > Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', > 'dump'] Pinpointing the failure. I guess `ghc-pkg dump` is not supposed to write to stderr, but it does. Unfortunately, the test driver doesn't seem to tell us what's the error from ghc-pkg. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SSH failing on Windows
On 22. 8. 2016 12:15, Erik de Castro Lopo wrote: > And then I read the error message. That message suggests that the SSH key > is not known by the remote repository. Did you copy your SSH keys from > your old machine to your new machine? That was maybe also covered, see the quote below. > Simon Peyton Jones via ghc-devs wrote: >> I have a .ssh directory set up, with a copy of all the files that used to >> work. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Msys2 64: progress
On 30. 6. 2016 14:53, David Macek wrote: > Weird. My MSYS2 autodetects and sets `LANG=en_US.UTF-8`. Can you try setting > that in the terminal before running `./boot` and or the testsuite? In bash, that's `export LANG=en_US.UTF-8`. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Msys2 64: progress
On 30. 6. 2016 14:38, Simon Peyton Jones via ghc-devs wrote:
> BTW, during ./boot, I get a lot of errors like this. Should I worry?
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>LC_ALL = (unset),
>LANG = "ENG"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
Weird. My MSYS2 autodetects and sets `LANG=en_US.UTF-8`. Can you try setting
that in the terminal before running `./boot` and or the testsuite?
--
David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Msys2 64: progress
On 29. 6. 2016 13:16, David Macek wrote: > On 29. 6. 2016 0:27, loneti...@gmail.com wrote: >> In any case, downgrading back to 7.48.0 worked for me. >> >> I don’t know how to do that with pacman > > curl -Os http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz > curl -Os http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz > pacman -U libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz > rm libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz Oops. If curl doesn't work, substitute with wget as per Tamar's advice, but `pacman -U` is still the right way to install stand-alone package files. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Msys2 64: progress
On 29. 6. 2016 0:27, loneti...@gmail.com wrote: > In any case, downgrading back to 7.48.0 worked for me. > > I don’t know how to do that with pacman curl -Os http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz curl -Os http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz pacman -U libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz rm libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: msys2 64 bit: help help!
> I have another issue. I'm using 'magit' (in emacs) to drive git. But it > gives half-minute delays to do anything at all. There are lots of people > complaining about it (googlable) but no solutions I can see. Do I have to > give up magit? I've read about it too, but I don't remember seeing any solutions. I don't use magit nor emacs, but I have two ideas: a) Try `mingw-w64-x86_64-emacs` (through pacman) with `mingw-w64-x86_64-git` (download[2] or through pacman[1]). This should work around any performance issues coming from the POSIX emulation layer. The downside is that I have no idea whether this combination works well currently (or at all). b) `git config core.fscache true`. I'm not sure if this option is supported under Cygwin. [1] <https://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper> [2] <https://git-for-windows.github.io/> -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: msys2 64 bit: help help!
On 27. 6. 2016 23:33, Simon Peyton Jones via ghc-devs wrote: > 1. I just left the machine for 10-15 mins and lo! the shell windows opened > up. It just took a lng time. I could be something with Active Directory. Cygwin (upon which is MSYS2 based) integrates with AD, but there are numerous (google-able) reports of huge slowdowns related to this. > At this point, starting a new shell no longer took a long time. It all > seemed to be working. Also don't forget to exclude `C:\msys64` from any anti-virus scans. > 2. I then ran pacman -Syuu as instructed on the installation page: > https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ I'm afraid you misread the instructions. You should run `update-core` first to upgrade to the newer pacman that handles `pacman -Syuu` correctly. (New installer packages with an up-to-date pacman are planned.) > The log of what happened is below. There are numerous failures involving > Cygwin, which I do not have installed, at least not so far as I know. I do > not know if these failures matter. They might. See below. > 3. After this step, starting a shell failed altogether with > "c:/msys64/mingw64_shell.bat is not recognised as an internal or external > command". And sure enough, there is no such file. Presumably it existed in > step 1. So perhaps step 2 deleted it? If the post-install script for `filesystem` were able to run, it would inform you that `*_shell.bat` are deprecated and were removed. I see you have `msys2-launcher-git` installed -- you can then use `C:\msys64\mingw64.exe` (and even pin it to the taskbar). > 4. As you mention, I then tried msys2_shell.cmd. It worked -- with a > noticeable delay of 5 seconds or so. May still be AD-related. > * should I worry about all those install errs I recommend staying on the safe side and nuke the installation. Alternatively, reinstall the packages that had failures (`pacman -S gcc-libs gettext gmp ...`). > * how can I debug what's happening with > that long delay `/etc/nsswitch.conf` allows for some configuration. See <https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-pwdgrp>. > * Should I nuke the start menu shortcuts that > the msys64 installer so carefully installed > in favour of msys2_shell.cmd? Yes or see above. Note that you might need `msys2_shell.cmd -mingw64` instead (not sure if it matters for GHC). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: msys2 64 bit: help help!
On 27. 6. 2016 10:01, Simon Peyton Jones via ghc-devs wrote: > Friends, esp Tamar, > > I am in happy possession of a new Surface Book, running Windows 10, which is > delightful – except that I can’t make the msys64 installation work, which is > crucial for GHC. Can any of you help? > > ·I install it from here: > https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems to be > the canonical place. The actual 64-bit exe seems to be > msys2-x86_64-20160205.exe. > > ·Installation goes fine > > ·But when I launch the “MinGW-w54 Win64 shell” from the Start menu, > the screen flashes as if it is briefly putting up a window, but then the > window disappears. > > ·Each time I do this the task manager shows that there is another > running ‘mintty.exe’. But it has no visible window > > > > Does anyone have any idea what I can do or how I can investigate? I can’t do > any GHC development without this! Hi. Please try `C:\msys64\usr\bin\mintty.exe -h always -` (incl. the trailing dash). You can also try `C:\msys64\usr\bin\bash.exe -li` in case the culprit is really mintty. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1
On 13. 1. 2016 16:43, Ben Gamari wrote: > Also note that we currently cannot offer 32-bit Windows builds due to > breaking changing in a recent Windows 10 upgrade. We'll work to > resolve this before the 8.0 release but please let us know if this poses > a significant problem for you. > [1] https://cygwin.com/ml/cygwin/2015-12/msg3.htm I believe that issue is resolved in latest msys2-runtime. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Window build broken
On 18. 11. 2015 9:29, Simon Peyton Jones wrote: > It’s msys2. I don’t have Cygwin on this machine. I have no idea where that > prompt comes from, but I agree it’s suspicious. Looks like your /etc/fstab is wrong. There should be a line like this one, that removes the `cygdrive` prefix from Windows drive/letter mounts: none / cygdrive binary,posix=0,noacl,user 0 0 -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Window build broken
On 17. 11. 2015 23:31, Simon Peyton Jones wrote: > Sigh. My Windows build is broken. See below. Any ideas? The stage2 > complier in non-interactive mode works ok. It’s just ghci fails. What does > “Not x86_64 PEi386” mean? What can I do to fix? Maybe it's obvious and you already checked, but could it be that the object file is for a different architecture? What does `file` say about it? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MSYS2 package for GHC 7.10.1
On 24. 5. 2015 8:43, someone wrote: Hi, Hi. First off, let me note that I proposed multiple things and each affects this in a different way (and some not at all). I saw your email at ghc-devs (I couldnt reply to your email because I wasnt subscribed at the time, hence this email) regarding msys2, and was wondering how it would affect the msys instructions at : https://wiki.haskell.org/Windows#Quickstart_on_Windows_7 Note that these steps results in a setup roughly equivalent to the one MinGHC provides. Currently I use these instructions to setup ghc in msys2, but I suspect these would change following your modifications. If the mingw-unbundling proposal goes through and the MSYS2 package gets sanctioned, the new steps would be: 1. Install MSYS2 and update using pacman 2. Install ghc and cabal-install packages using pacman For usage inside a POSIX shell, launch mingw64_shell.bat. For usage outside of MSYS2, add `$msysroot/mingw64/bin` to PATH. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MSYS2 package for GHC 7.10.1
On 22. 5. 2015 15:58, Yitzchak Gale wrote: Wow, this sounds great! Just to clarify - this would still be a mingw-w64 build and not require the msys2 DLLs, correct? Correct. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: MSYS2 package for GHC 7.10.1
With the helpful pointers from ezyang on IRC, I pushed this a bit forward. I converted most of the patches into more reasonable commits including short descriptions and created a git branch for it. See https://github.com/ghc/ghc/compare/ghc-7.10.1-release...elieux:msys2-pkgbuild. As mentioned previously, the changes should be uncontroversial except for two big changes: removing bundled mingw, perl and touchy and changing the directory layout. While the directory layout change is mostly self-contained (barring any tools hardcoding ..\lib), the bundled dependency removal will required major changes to the build process. My proposals follow. For hacking on GHC == 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Get a GHC repository ready 3. Hack, hack, hack 4. Build and test as usual 5. GOTO 3 Alternatively, this could be replaced with a makepkg-based flow: 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Get a mingw-w64-ghc-git PKGBUILD 3. $ makepkg-mingw --nobuild # clone the repositories 4. Go to src/ghc and hack, hack, hack 5. $ makepkg-mingw --noextract --noprepare --noarchive # build and test 6. GOTO 4 For binary release == Phase 1: pacman package. This can be done in coordination with the MSYS2 maintainers, or a separate GHC-owned pacman repository can be created. 1. Get MSYS2, update and install dependencies (including the bootstrapping ghc that would come as a MSYS2 package) 2. Update the mingw-w64-ghc PKGBUILD to point to the new source release 3. $ makepkg-mingw # build a package 4. Upload the package to a pacman repository Phase 2: stand-alone bindist 1. Download the package and its dependencies 2. Extract them into a temporary directory 3. Create a tarball or an installer from that 4. Upload to GHC servers This is essentially what the new Git for Windows does (and what some other projects that use MSYS2 as their build environment do). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Automating GHC build for Windows
I hope you don't mind me posting to an old thread. I'm re-building ghc-7.10.1 a lot these days and there is one recurring permission issue that looks awfully similar to the ones mentioned here. The issue seems to be deterministic -- appears on every build IIRC and cannot be fixed by re-running make. My real-time malware scanner is disabled and I assume it's not caused by indexing services. The problem seems to be due to botched ACLs in/of the /tmp directory. Some of the files/directories inside are undeletable by the user which is running the build and some can't be deleted even with admin rights. To fix this, I have to force take ownership and grant myself permissions on the files/directories. The build can't continue even after emptying the /tmp directory, as the permissions on the directory itself seems to be broken -- so much that Windows Explorer refuses to show the Advanced Security Settings window for it. Deleting the directory and re-creating with correct permissions allows the build to continue. The tail of a failing build log follows. Unfortunately, it doesn't tell much about the operation that failed. I hope I'll be able to find some time to find out what's failing and what's causing the permissions change. inplace/bin/ghc-cabal check libraries/ghc-prim inplace/bin/ghc-cabal configure libraries/ghc-prim dist-install --with-ghc=buildir/inplace/bin/ghc-stage1 --with-ghc-pkg=buildir/inplace/bin/ghc-pkg --flag=include-ghc-prim --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --configure-option=CFLAGS= -fno-stack-protector--configure-option=LDFLAGS= --configure-option=CPPFLAGS=--gcc-options= -fno-stack-protector --with-gcc=/mingw64/bin/gcc --with-ld=/mingw64/bin/ld --configure-option=--with-cc=/mingw64/bin/gcc --with-ar=/mingw64/bin/ar Configuring ghc-prim-0.4.0.0... ghc-cabal.exe: permission denied libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (Paths starting with buildir were shortened by me for the purpose of posting here.) -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows build gotchas
On 1. 1. 2015 19:01, Martin Foster wrote: Hello all, I've been spending some of my winter break trying my hand at compiling GHC, with a mind to hopefully contributing down the line. I've got it working, but I ran into a few things along the way that I figure might be worth fixing and/or documenting. In the approximate order I encountered them: * The first pacman mirror on the list bundled with MSYS2 is down, with the result that every download pacman makes takes ~10sec longer than it should. It downloads a lot, so that really adds up - but it's easy to fix, just pacman -Sy pacman-mirrors before doing anything else with it. Is that worth mentioning on the wiki? I was thinking a line on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows could be helpful. This is an unfortunate, but temporary situation. The next MSYS2 installer will come with updated mirror lists. I don't know what's the policy on including this kind of information on the wiki. * That page mentions If you see errors related to fork(), try closing and reopening the shell - I've determined that you can reliably avoid that problem by following the instructions at http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/#iii-updating-packages, ie by running pacman --needed -S bash pacman msys2-runtime, then closing re-opening the MSYS shell, before you tell pacman to install the GHC prerequisite packages. This may be true for the GHC guide, but AFAIK if you decide to install other packages, you may still encounter fork errors. The installation process is taken care of by updating bash, pacman and the runtime separately, but subsequent invocations of MSYS2 programs could still fail due to newly installed MSYS2 libraries (if any). * And finally, the big one: cabal and/or ghc-pkg put some files outside the MSYS root directory, and caused me no end of trouble in doing so... I made a bit of a mess at one point, and tried to fix it by starting over completely from scratch. I expected uninstalling reinstalling MSYS to achieve this (it deletes its root directory when you uninstall it), but that left me with a huge pile of errors when I tried to run cabal install -j --prefix=/usr/local alex happy, of the form Could not find module `...': There are files missing in the `...' package. I noticed that the cabal output made reference to C:\Users\Martin\AppData\Roaming\cabal\, so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, %APPDATA%\cabal, there were also files left over in %APPDATA%\ghc. Once I removed that directory as well, things started working again - but it took me a lot of time frustration to get there. I'm not entirely sure, but I think the copy of Cabal I already had from installing the Platform may also have been storing files in those directories, in which case this process completely mangled them - which isn't great. It seems to me that, ideally, the build GHC inside MSYS procedure would keep itself entirely inside the MSYS directory structure: if it were wholly self-contained, you'd know where everything is, and it couldn't break anything outside. As far as I can tell, the only breach is those two directories courtesy of Cabal, so I didn't think it would be too difficult - but none of the things I've tried (the --package-db cabal flag, a custom cabal --config-file, setting the GHC_PACKAGE_PATH environment variable, maybe some others I've forgotten) had the desired effect. Is it possible? Is it even a good idea? If that's just how it has to be, I feel like there should be an obvious note somewhere for the sake of the next person to trip over it. I had problems with this also, so I definitely support mentioning these two on the wiki. If we ever get to having a ghc package for MSYS2, it will use $HOME instead of $APPDATA, but that won't actually help with the problem of MSYS2 re-install not cleaning everything the build left behind. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 5. 11. 2014 18:13, Gintautas Miliauskas wrote: Thanks for pointing out that virus scanners could be an issue. I found that Microsoft Security Essentials realtime scanning was on. I'll try disabling it and see if that helps with the -j5 case. For what it's worth, I tried disabling the virus scanner, but it did not help, 4/8 validation runs segfaulted (-j5). Can you dump your package versions here? Use pacman -Qe. I want to try the build with a replica of your environment. Also, does 4/8 mean that some builds were without errors? Maybe I haven't done enough runs. Could you attach the script you use for running validate in a loop? (I'm sure it's simple enough for me to write it, but if I can avoid it...) -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
Sorry for the large amount of messages. On 5. 11. 2014 8:01, David Macek wrote: I'm running validate to double check (detected 4 CPUs). I got the validate results: Unexpected results from: TEST=linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924 T7702 plugins01 T6106 ghci038 T8172 ghci032 T5975a T5975b ghci058 T3064 T3307 environment001 T876 T3738 T4830 T5205 T7436 lazy-bs-alloc T1407 rdynamic T7037 T5423 T8124 T5435_dyn_asm prog012 prog013 prog001 prog002 prog003 T4006 OVERALL SUMMARY for test run started at 11/05/14 09:04:01 Central Europe Standard Time 1:01:50 spent to go through 4095 total tests, which gave rise to 14911 test cases, of which 11167 were skipped 58 had missing libraries 3578 expected passes 71 expected failures 1 caused framework failures 1 unexpected passes 36 unexpected failures Unexpected passes: rts linker_unload (normal) Unexpected failures: ../../libraries/base/tests T4006 [bad stdout] (normal) ../../libraries/base/tests/IO T3307 [bad exit code] (normal) ../../libraries/base/tests/IO environment001 [bad stdout] (normal) cabal ghcpkg05 [bad stderr] (normal) callarity/perf T3924 [stat too good] (normal) ghci.debugger/scripts listCommand002 [bad stderr] (ghci) ghci/linking T1407 [bad stderr] (ghci) ghci/prog001 prog001 [bad stderr] (ghci) ghci/prog002 prog002 [bad stderr] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) ghci/prog012 prog012 [bad stderr] (ghci) ghci/prog013 prog013 [bad stderr] (ghci) ghci/scripts T5975a [bad stderr] (ghci) ghci/scripts T5975b [bad stderr] (ghci) ghci/scripts T6106 [bad stderr] (ghci) ghci/scripts T8172 [bad stdout] (ghci) ghci/scripts ghci032 [bad stderr] (ghci) ghci/scripts ghci038 [bad stderr] (ghci) ghci/scripts ghci058 [bad stderr] (ghci) llvm/should_compileT5486 [stderr mismatch] (optllvm) llvm/should_compileT5681 [stderr mismatch] (optllvm) llvm/should_compileT7571 [stderr mismatch] (optllvm) perf/compiler T3064 [stat not good enough] (normal) perf/should_runT3738 [stat too good] (normal) perf/should_runT4830 [stat too good] (normal) perf/should_runT5205 [stat too good] (normal) perf/should_runT7436 [stat too good] (normal) perf/should_runT876 [stat not good enough] (normal) perf/should_runlazy-bs-alloc [stat not good enough] (normal) pluginsplugins01 [bad stderr] (normal) rtsT5423 [bad stdout] (normal) rtsT5435_dyn_asm [bad stdout] (normal) rtsT7037 [bad stdout] (normal) rtsT8124 [exit code non-0] (threaded1) rtsrdynamic [bad exit code] (normal) simplCore/should_compile T7702 [stderr mismatch] (normal) I assume that means the build itself had no errors. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 13:07, Gintautas Miliauskas wrote:
But running it just prints hi, no indications of a crash or anything,
regardless of the value of the MSYS variable:
Either the compiler, or C library is too smart for this. I'd guess your
compiler is working with undefined behavior optimizations, because with my
compiler, I get both hi and bye (or not, when I pass -Og). Try this code:
#include stdio.h
int main() {
printf(hi\n);
((void(*)())(0))();
printf(bye\n);
return 0;
}
--
David Macek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 1:30, Ray Donnelly wrote: Finally, can anyone else confirm the problem? I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 14:14, Gintautas Miliauskas wrote: I'm working on ghc trunk. I'm trying to reproduce your errors, but I failed at ./boot with: Booting . 'autoreconf' is not recognized as an internal or external command, operable program or batch file. Running autoreconf failed with exitcode 256 at ./boot line 163, PKGS line 12. It seems that /mingw64/bin/perl's system(autoreconf) fails to execute because it's passing the command line to cmd, not bash (/usr/bin/autoreconf is a script). Gintautas, do you have mingw-w64-x86_64-perl installed? Can we do something about this, or is boot going to work only in pure msys2 shell? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
Hi. I just built GHC from master (1c35f9f1cb7a293da85d649904ce731a65824cfe) in my somewhat outdated MSYS2. I followed the wiki page with a few exceptions. - I cleared my PATH before running the shell (I left only Windows and System32) - my installation is not up-to-date - I do not have msys2 libtool, automake nor binutils; if the build used any of those, they came from mingw64 or from the host ghc - I had to run boot in pure msys2 shell, because mingw64 perl caused it to fail I saw no segfaults, but I may have missed them. I did not get a ghc.exe, but that may be correct behavior for all I know. My simple test program compiled and ran fine. I saw a lot of warnings during ghc's build though: - checking for DocBook DTD... I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd - something with not finding any implementation of a module out of [ xxx.dylib, xxx, ... ], I think it was in cabal builds - could not find link destionations for: xxx I hope it helps somehow. Maybe your issues come from mixing msys2 and mingw toolchain after all. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 23:20, Gintautas Miliauskas wrote: ghc should appear as inplace/bin/ghc-stage2.exe after a successful build. It's there. Did you run make with parallelism? I don't have a smoking gun, but the build seems to be somewhat stable with -j1, while it crashes a lot of the time with -j5 (I have a 4-core CPU). I have only tried a couple of runs with -j1 (takes a while...), so I can't say for sure that non-parallel builds are stable, but 2/2 runs succeeded. Nope. I'll try with -j5. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 23:23, David Macek wrote: Nope. I'll try with -j5. So that looks like another successful build. Unless make can ignore the -j argument, I'd say the issue is caused or activated by your configuration. I'm running validate to double check (detected 4 CPUs). Maybe we should work out a precise, minimalistic recipe to replicate the issue (I haven't tried installing clean MSYS2 yet). By the way, have you ruled out anti-virus software (and other BLODApps) as a possible cause? -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 0:07, Gintautas Miliauskas wrote: A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit tricky (some Haskell tools need to be preinstalled). I'm not sure how useful it would be since for Windows there is already a nicely packaged native Haskell Platform installer. It definitely helps MSYS2 users by providing an easily installable ghc package. That in turn could help with setting up ghc development environment. Hopefully after Windows ghc migrates to gcc 4.8, ghc package will be able to use the MSYS2 packaged toolchain to reduce duplication. I have this so far, but I give no guarantees: https://github.com/elieux/MINGW-packages/tree/ghc To use: - download ghc and put it in PATH - optionally alter ghc/lib/settings to use MSYS2 toolchain instead of the bundled one (see below) - use cabal-install PKGBUILD to build Cabal and put it in PATH - use built Cabal to download and build Alex and Happy and put them in PATH (I think they're installed somewhere inside AppData by default) - run ghc PKGBUILD Related: https://www.haskell.org/pipermail/ghc-devs/2014-October/006759.html My ghc/lib/settings (from version 7.6.3): [(GCC extra via C opts, -fwrapv), (C compiler command, gcc.exe), (C compiler flags, -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads), (ar command, ar.exe), (ar flags, q), (ar supports at file, YES), (touch command, $topdir/touchy.exe), (dllwrap command, dllwrap.exe), (windres command, windres.exe), (perl command, perl.exe), (target os, OSMinGW32), (target arch, ArchX86_64), (target word size, 8), (target has GNU nonexec stack, False), (target has .ident directive, True), (target has subsections via symbols, False), (LLVM llc command, ), (LLVM opt command, ) ] -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 1:05, Gintautas Miliauskas wrote: Nice! This needs a host ghc (with alex and happy) preinstalled, correct? Maybe I misunderstood, but the answer should be clear from my message. Yes, the ghc PKGBUILD expects working ghc, alex and happy in PATH. ghc has to be downloaded (until an MSYS2 package becomes available), cabal can be built using cabal-install PKGBUILD and alex and happy can then be downloaded and built using cabal. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
