#9503: Cross compiling with mingw uses wrong gcc
-------------------------------------+-------------------------------------
Reporter: Kritzefitz | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Build System | Version: 7.8.3
Keywords: Cross compiling | Operating System: Linux
Architecture: x86 | Type of failure: Building
Difficulty: Unknown | GHC failed
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Greetings,
I tried to cross compile a cross compiler ghc on Debian jessie Linux/GNU
i386.
I configured with "./configure --target=x86_64-w64-mingw32" (log
attached).
The configure script runs and then wants to use the native gcc
(/usr/bin/gcc) instead of the mingw one
(/usr/bin//usr/bin/x86_64-w64-mingw32-gcc).
Thus the mingw headers (in /usr/x86_64-w64-mingw32/include/) aren't found,
which leads to errors during compiling (relevant part attached).
Regards
Sven
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9503>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7015: Add support for 'static'
-------------------------------------+-------------------------------------
Reporter: edsko | Owner:
Type: feature | Status: patch
request | Milestone: 7.10.1
Priority: normal | Version: 7.4.2
Component: Compiler | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets:
None/Unknown |
Test Case: |
Blocking: |
Differential Revisions: Phab:D119 |
-------------------------------------+-------------------------------------
Comment (by facundo.dominguez):
Forbidding polymorphic types in the static form makes it less obvious
defining a combinator like the following:
{{{
staticCompose :: Static (b -> c) -> Static (a -> b) -> Static (a -> c)
staticCompose sf sg = staticLabel (static (.)) `staticApply` sf
`staticApply` sg
}}}
This is actually defined in the version of distributed-static in hackage:
{{{
composeStatic :: (Typeable a, Typeable b, Typeable c) => Static ((b -> c)
-> (a -> b) -> a -> c)
composeStatic = staticLabel "$compose"
staticCompose :: (Typeable a, Typeable b, Typeable c)
=> Static (b -> c) -> Static (a -> b) -> Static (a -> c)
staticCompose g f = composeStatic `staticApply` g `staticApply` f
}}}
It doesn't mean that we can't live with the restriction, but we will have
to figure out the impact upwards before committing, I guess.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7015: Add support for 'static'
-------------------------------------+-------------------------------------
Reporter: edsko | Owner:
Type: feature | Status: patch
request | Milestone: 7.10.1
Priority: normal | Version: 7.4.2
Component: Compiler | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets:
None/Unknown |
Test Case: |
Blocking: |
Differential Revisions: Phab:D119 |
-------------------------------------+-------------------------------------
Comment (by edsko):
One thing I was wondering about: clearly, solving the general problem of
impredicativity would take us way off too far here; but if the type
checker ''knows'' about static, just like, say, it knows about ADTs, then
perhaps it wouldn't be too difficult to support things like `static
(forall a. a -> a)`, just like it supports universally quantified types as
arguments to ADT constructors?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7015: Add support for 'static'
-------------------------------------+-------------------------------------
Reporter: edsko | Owner:
Type: feature | Status: patch
request | Milestone: 7.10.1
Priority: normal | Version: 7.4.2
Component: Compiler | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets:
None/Unknown |
Test Case: |
Blocking: |
Differential Revisions: Phab:D119 |
-------------------------------------+-------------------------------------
Comment (by simonpj):
Edsko my remark about a "hack" was not intended as a criticism. Of course,
if GHC is inadequate you must hack around its shortcomings. My intent was
solely this: let's not enshrine a temporary hack into the design of the
language that GHC implements.
There are two things going on in this ticket:
* What should be the specification of the feature that GHC implements?
I think we are agreeing that: the argument of `static` should have no free
type variables. Let's put that into the spec.[[BR]][[BR]]
That leaves open the question of adding an impredicative-like feature,
the ability to have terms of type `Static (forall a. [a] -> [a])`, which
make perfect sense, have no free type variables, but which are disallowed
at present.
* Given the above restriction, and the absence of the impredicative
support, how can we hack around the restriction to get something like
polymorphism. This is the `Any` discussion on #9429. Even lacking a fix
for poly-kinded `Any`, it's not a disaster because for any particular kind
we can always do the job; it's just a bit inelegant.
If we agree about these things, perhaps you can update the wiki page as
above and we can go from there.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#110: Cygwin binaries
-------------------------------------+-------------------------------------
Reporter: fizzgig | Owner:
Type: feature | Status: new
request | Milestone: ⊥
Priority: normal | Version: None
Component: None | Keywords:
Resolution: None | Architecture: Unknown/Multiple
Operating System: Windows | Difficulty: Unknown
Type of failure: | Blocked By:
None/Unknown | Related Tickets:
Test Case: N/A |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Description changed by kfrdbs:
Old description:
> {{{
> A complete set of binaries for ghc and ghci under
> cygwin would be really nice.
>
> Using the win32-version works, but is far from satisfying.
>
> GHCI does not recognize the arrow keys, thus no
> command history (annoying errors instead) and I've
> heard others complain about problem with linking, since
> win32-ghc uses it's own gcc.
>
> I tried to compile ghc myself, but gave up after a few
> hours.
>
> Please compile it and include it in cygwin's auto-update
> system.
>
> Test
> }}}
New description:
{{{
A complete set of binaries for ghc and ghci under
cygwin would be really nice.
Using the win32-version works, but is far from satisfying.
GHCI does not recognize the arrow keys, thus no
command history (annoying errors instead) and I've
heard others complain about problem with linking, since
win32-ghc uses it's own gcc.
I tried to compile ghc myself, but gave up after a few
hours.
Please compile it and include it in cygwin's auto-update
system.
}}}
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/110#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#110: Cygwin binaries
-------------------------------------+-------------------------------------
Reporter: fizzgig | Owner:
Type: feature | Status: new
request | Milestone: ⊥
Priority: normal | Version: None
Component: None | Keywords:
Resolution: None | Architecture: Unknown/Multiple
Operating System: Windows | Difficulty: Unknown
Type of failure: | Blocked By:
None/Unknown | Related Tickets:
Test Case: N/A |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Description changed by kfrdbs:
Old description:
> {{{
> A complete set of binaries for ghc and ghci under
> cygwin would be really nice.
>
> Using the win32-version works, but is far from satisfying.
>
> GHCI does not recognize the arrow keys, thus no
> command history (annoying errors instead) and I've
> heard others complain about problem with linking, since
> win32-ghc uses it's own gcc.
>
> I tried to compile ghc myself, but gave up after a few
> hours.
>
> Please compile it and include it in cygwin's auto-update
> system.
> }}}
New description:
{{{
A complete set of binaries for ghc and ghci under
cygwin would be really nice.
Using the win32-version works, but is far from satisfying.
GHCI does not recognize the arrow keys, thus no
command history (annoying errors instead) and I've
heard others complain about problem with linking, since
win32-ghc uses it's own gcc.
I tried to compile ghc myself, but gave up after a few
hours.
Please compile it and include it in cygwin's auto-update
system.
Test
}}}
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/110#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9344: takeWhile does not participate in list fusion
-------------------------------------+-------------------------------------
Reporter: dfeuer | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version: 7.8.3
Keywords: | Differential Revisions:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+-------------------------------------
`takeWhile` doesn't do the list fusion thing. This alternative definition
seems to fix that, at least to a great extent. It fused completely in a
simple test, and incompletely but still usefully in a more complex one. I
don't know how to write the appropriate translate/untranslate RULES for it
yet.
{{{
#!haskell
{-# LANGUAGE ScopedTypeVariables #-}
takeWhileFB :: forall a . (a -> Bool) -> [a] -> [a]
takeWhileFB p xs = build tw'
where
tw' :: forall b . (a -> b -> b) -> b -> b
tw' kons knil = foldr go knil xs
where
go x rest | p x = x `kons` rest
| otherwise = knil
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9344>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
