Hi
Windows XP, GHC HEAD, checkout a few hours ago:
make[2]: Entering directory
`/cygdrive/c/ghc-build/ghc/libraries/process'
c:/ghc-build/ghc/ghc/stage1-inplace/ghc.exe -package-name
process-1.0.1.1 -hide-
all-packages -no-user-package-conf -i -idist/build -i.
-idist/build/autogen -Idi
st/build/a
Error 2
Thanks
Neil
> -Original Message-
> From: Simon Marlow [mailto:[EMAIL PROTECTED] On
> Behalf Of Simon Marlow
> Sent: 06 November 2008 4:52 pm
> To: Mitchell, Neil
> Cc: cvs-ghc@haskell.org
> Subject: Re: Windows building failure
>
> Si
Hi,
I think this bug might deserve some GHC attention, it could
(potentially) be a show-stopped for quite a few Windows users. It would
certainly be good to get this fix into 6.10.2, and depending on how many
users it effects, maybe even reroll the Windows installer.
http://hackage.haskell.org/tr
Hi,
With the latest HEAD from this morning, I fail to build:
c:/ghc-build/ghc/ghc/stage1-inplace/ghc -optc-Werror -optc-Wall -optc-W
-optc-Ws
trict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Win
line -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel
-
w am down to one failure:
Unexpected failures:
break008(ghci)
Thanks
Neil
>
> 2008/10/22 Mitchell, Neil <[EMAIL PROTECTED]>:
> > Hi
> >
> >
> >> > Could it be that buffering has a different default on Windows?
> >>
> >> 2228 i
Hi
> > Could it be that buffering has a different default on Windows?
>
> 2228 is now an expected failure on Windows. See #2628.
Fair enough.
> > As a secondary issue, it appears that the failure reports
> are occuring
> > after the script has started to print out information about
> the n
breakpoint.
+Perhaps no modules are loaded for debugging?
+[]
*** unexpected failure for break008(ghci)
And a GHCi debugger issue.
As a secondary issue, it appears that the failure reports are occuring
after the script has started to print out information about the next
test.
Thanks
Neil
>
Hi,
Doing validation under Windows XP, using HEAD from a few hours ago, I
get the results:
OVERALL SUMMARY for test run started at The current date is: 17/10/2008
Enter the new date: (dd-mm-yy)
2221 total tests, which gave rise to
8313 test cases, of which
0 caused framework failur
> > Yes, I don't have the test suite. The "testsuite" directory
> does not
> > exist.
> >
> > How do I get the test suite? I would have expected the
> details to be
> > at the top of this page:
> > http://hackage.haskell.org/trac/ghc/wiki/Building/RunningTests
>
> ./darcs-all --testsuite get
t; Sent: 15 October 2008 9:22 am
> To: Mitchell, Neil
> Cc: cvs-ghc@haskell.org
> Subject: Re: Validate fails on Windows
>
> Ignore the documentation errors. You seem to simply have no
> testsuite.
>
> 2008/10/15 Mitchell, Neil <[EMAIL PROTECTED]>:
> > Hi,
&
Hi,
Using GHC Head from yesterday afternoon, Validate fails on Windows:
Warning: ghc-6.11.20081014:VectType: could not find link destinations
for:
VectType.Repr
Warning: ghc-6.11.20081014:TcClassDcl: could not find link destinations
for:
TcClassDcl.TcMethInfo
Warning: ghc-6.11.20081014:Hs
Hi
> Right, this is another interesting alternative. But since it
> requires users to define their own instances all over the
> place anyway I would almost be happier to provide our own
> version of the binary package to
> users: they would be free to define their (de)serialization
> methods u
Hi
Both are valid problems. Indeed, Data /= Binary, but does provide handy
serialisation in a lot of cases.
One way round both issues you raise is to have a GhcTransform class,
with two transform methods, one which is applied to the data before
writing and the other after reading - giving the typ
Hi,
There is an alternative 4:
Require Data/Typeable instances for all items, then using runtime
reflection provided by Data serialise the values into binary (or however
else you want them).
* You don't get any additional dependencies (other than perhaps SYB,
which I hope you are going to add fo
> > > Re: strip installPackage
> > >
> > > I ran into this too, I'm just testing the fix.
> >
> > I notice you committed a pile of patches, but nothing that seems to
> > have dealt with this issue. I'm just checking that the patch wasn't
> > overlooked (no hurry if it was deliberately not pushe
Hi
> Re: strip installPackage
>
> I ran into this too, I'm just testing the fix.
I notice you committed a pile of patches, but nothing that seems to have
dealt with this issue. I'm just checking that the patch wasn't
overlooked (no hurry if it was deliberately not pushed)
Thanks
Neil
=
Hi,
Using HEAD from today, during build, I get:
Configuring installPackage-1.0...
Warning: This package indirectly depends on multiple versions of the
same
package. This is highly likely to cause a compile failure.
package process-1.0.0.1 requires filepath-1.1.0.0
package directory-1.0.0.1 requir
Hi,
I decided I should try and do a validation, but it failed:
typecheck/TcEnv.lhs:71:0:
Warning: Module `PrelNames' is imported, but nothing from it is
used,
except perhaps instances visible in `PrelNames'
To suppress this warning, use: import PrelNames()
:
Faili
Hi Ian
> Wed Oct 1 10:11:33 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
> * On Windows, check that we have a good version of windres
> when configuring
>
> M ./aclocal.m4 +40
> M ./configure.ac +3
This patch is incorrect.
In ghc/distrib/prep-bin-dist-mingw we copy $mingw_bin/windres.ex
Hi
> I
> still don't see how 'perl'
> could pick up a perl that isn't on the PATH,
I suspect I had a different $PATH in both cases, one was before ICFP,
one was after - and my path is fairly fluid.
Thanks
Neil
==
Plea
Hi Claus,
> The ghc 6.8.3 perl probably shouldn't be on your PATH.
$ which perl
/usr/bin/perl
It isn't at the moment - perhaps some other things have changed in the
meantime which means its no longer required. However, I noticed that all
other invokations of perl follow the pattern of ./script,
Hi,
My Windows tree still requires one patch to build successfully, which is
attached.
Thanks
Neil
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mitchell, Neil
> Sent: 16 September 2008 2:44 pm
> To: cvs-ghc@haskell.org
> Su
Hi Ian,
> > If I darcs get the time library, using a GHC binary distribution,
> > isn't runhaskell Setup configure/build/install sufficient?
> I thought
> > Cabal was meant to do this magic for me. I realise when building
> > in-tree time configure based things are required.
>
> No: Building
Hi
> > Yes, and building the darcs version of time doesn't work.
>
> You need to run autoreconf if you get the darcs version.
If I darcs get the time library, using a GHC binary distribution, isn't
runhaskell Setup configure/build/install sufficient? I thought Cabal was
meant to do this magic fo
the Haskell Platform,
> which will come out soon (maybe 1 month) after GHC is released.
>
> On Fri, Sep 19, 2008 at 11:01 AM, Mitchell, Neil
> <[EMAIL PROTECTED]> wrote:
> > Hi Duncan,
> >
> > I have previously been very enthusiastic about advocating the
>
Hi Duncan,
I have previously been very enthusiastic about advocating the inclusion
of the Cabal program in GHC 6.10.1 - I still consider it essential for
Windows users. However, GHC HEAD doesn't currently put it in the
bindist, which is what I think will end up shipping to users. Given that
the re
Hi Ian
> > However, the exact same "time" issues do crop up if I try
> and install
> > the time package on a different machine (without mingw/cygwin etc)
> > using a binary distribution of GHC HEAD - so something
> seems wrong somewhere.
>
> Do you mean building a tarball from hackage doesn't
Hi
> I can confirm that the patch allows me to build on drive d:
> while /mingw only exists on drive c:, so that workaround
> solves my recent issue (and should mean that other people's
> build no longer work by accident only, reducing chances for
> obscure breakage). Neil: does it also render
> > Actually I've pushed an updated patch to Cabal HEAD, so I'm hoping
> > someone will test & validate that on Windows. Though it needs to be
> > tested by someone who was having the problem because it does not
> > happen for everyone (for reasons that are not very clear).
>
> I can confirm th
Hi Simon,
> I object (mildly) to having multiple sets of build
> instructions.
I object strongly, which is why Claus's instructions with an exact set
of instructions with absolutely no choices provided is so great. By
"preparing a set of instructions", I really just mean updating the
existing in
Hi
> >My preference is to use the latest versions, otherwise we'll
> run into
> >some other bug and the mingw people will (legitimately) tell
> us to use
> >a newer version, requiring us to upgrade everything anyway. I think
> >Claus disagrees with me on this.
>
> Actually, I don't disagree.
Hi
> > 2) cc1 is in the wrong place, and can't be found.
>
> isn't this just the fact that Cabal needs to pass -B to gcc?
> Does anyone know why we're still haven't this problem?
No idea. If you think its now fixed, let me know and I'll try again
without the modifications to my PATH.
> > 3) o
> | Yes, I've added notes where my experiences differ. Once I've got
> | everything working, and have identified which steps are going to be
> | worked around by the build system (i.e. cc1 issues), I'll merge my
> | changes in.
>
> Thank you! Do let me know when you do this.
Before I fix the
Hi
> > c:/darcs/HEAD/ghc/stage1-inplace/ghc.exe -package-name
> time-1.1.2.1 -hide-all-packages -no-user-package-conf -i
> -idist/build -i. -idist/build/autogen -Idist/build/autogen
> -Idist/build -Iinclude -optP-include
> -optPdist/build/autogen/cabal_macros.h -odir dist/build
> -hidir dist/
Hi Simon
> I'd really really like to end up
> a) with a build system that works
> b) with Wiki instructions that match it
The issues with (a) are fairly minor, so I don't think that will be too
much effort.
> Concerning the latter, Neil, you could fix the Wiki material
> directly couldn't you?
3 one, which doesn't
work. The shebang line is /usr/bin/perl which does work.
Thanks
Neil
> -Original Message-
> From: Mitchell, Neil
> Sent: 16 September 2008 10:24 am
> To: cvs-ghc@haskell.org
> Subject: Windows build issues
>
> Hi,
>
> I get the error:
Hi Claus,
Just reading through the Windows build instructions:
http://hackage.haskell.org/trac/ghc/wiki/Building/Windows
./configure --host=i386-unknown-mingw32 -with-gcc=C:/Mingw/bin/gcc.exe
--with-ld=C:/Mingw/bin/ld.exe
I notice that with-gcc has 1 dash before it, and with-ld has 2 dashes
befo
Hi,
I get the error:
windres --preprocessor="C:/Mingw/bin/gcc.exe -E -xc -DRC_INVOKED" -o
ghci.res -
i ghci.rc -O coff
C:/Mingw/bin/gcc.exe -o ghci -O ghci.o ghci.res
Finished making all in ghci: 0
== Finished making
UG, as far as I
can tell.
> Meanwhile, if you have an easy repro case, I'd be interested.
HEAD of Haddock gets these warnings reliably.
Thanks
Neil
> | -Original Message-
> | From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> | On Behalf Of Mitchell, Neil
>
Hi
Using GHC Head from yesterday, I am encountering loads of warnings about
too many specialisations for one function. Some of these warning
messages take up at least 10 screens. To give just one example, when
compiling haddock, the Hoogle backend gives:
C:\ghc\ghc-6.9.20080905\bin\ar.exe: creati
8 1:45 pm
> To: Mitchell, Neil
> Cc: cvs-ghc@haskell.org; Duncan Coutts
> Subject: Re: Failure to build Haddock with GHC HEAD on Windows
>
> Hi,
>
> On Thu, 11 Sep 2008 20:00:30 +0900, Mitchell, Neil
> <[EMAIL PROTECTED]> wrote:
> > Using a version of GHC HEA
Hi,
Using a version of GHC HEAD on Windows XP, built in the last hour, I get
a compilation failure when building haddock. It's possible this is a
Cabal issue, so I've cc'd Duncan.
I'm compiling haddock HEAD using GHC Paths 1.0.5. To compile haddock I
required two patches, which I've attached to t
42 matches
Mail list logo
