Windows build

Phyx lonetiger at gmail.com
Sat Jul 9 17:00:21 UTC 2016


Hi Simon,

Thomie changed it so the in place gcc can be called from the testsuite. The
tests should pass now.

Kind regards,
Tamar

Sent from my Mobile
On Jul 8, 2016 23:02, <lonetiger at gmail.com> wrote:

> Hi Simon,
>
>
>
> For these tests it shouldn’t matter much so I guess I can change them.
>
>
>
> The Windows Build guide does ask to put /mingw64/bin/ on your path.
>
> The reason I tend not to want to use GHC to compile my c files for the
> tests is that GHC doesn’t just pass the commands along to gcc.
>
> It adds to them. While for these single object files it doesn’t matter (as
> it just adds a few defines and include paths) It has bitten me multiple
> times in the past. Particularly when compiling shared libraries for tests
> since GHC wants to link in the RTS, which makes the files considerably
> larger and harder to debug so
>
> I tend to avoid using GHC to compile just pure C code.
>
>
>
> It means (with shared libraries) that I’ll end up with multiple RTSs
> loaded (at least in memory, which means stepping in gdb I have to keep
> track of the memory locations so I know which one I’m in). So I really wish
> there was a way  to tell GHC not to do this.
>
>
>
> Also you’ll likely be linking against libraries compiled against other
> versions of GCC or MSVC so that shouldn’t be an issue.
>
>
>
> I’ll change the tests tomorrow, but I would much prefer if the testsuite
> can tell me where the GCC to use is, so I don’t have to use GHC.
>
>
>
> Regards,
>
> Tamar
>
>
>
> *From: *Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org>
> *Sent: *Friday, July 8, 2016 22:27
> *To: *ghc-devs at haskell.org
> *Subject: *Windows build
>
>
>
> I’ve completed a successful build on my Surface Book!  Thank you.
>
>
>
> One last glitch. I’m getting the validate failure bellow.
>
>
>
> No other test requires gcc in my path.  GHC itself carefully navigates to
> its own private gcc.   Do we really want this family of tests (half a dozen
> variants of T11223) to rely on some random gcc, which might or might not be
> the same as GHC is using?  Shouldn’t we use ‘ghc foo.c’?
>
>
>
> Simon
>
>
>
> =====> T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1]
>
> cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test
> spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s
> --no-print-directory t_11223_simple_unused_duplicate_lib
>
> Wrong exit code (expected 0 , actual 2 )
>
> Stdout:
>
>
>
> Stderr:
>
> /bin/sh: gcc: command not found
>
> make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160709/b35dca3a/attachment.html>


More information about the ghc-devs mailing list