RE: [Haskell-cafe] GHC Core still supported?
Jim, and others (I'm ccing GHC users)
External Core is a feature of GHC that is lonely and unloved. External
Core longs to have someone to look after it, tell it that it is a Truly
Useful Feature, and keep it working.
Seriously, External Core has a strong tendency to bit-rot because (so
far as I can tell) few people seem to use it, and hence it can lag
behind changes in the rest of the compiler. Yes, in principle we at GHC
HQ should push the entire compiler along in sync, but there are just too
few hours in the day. Another contributory factor is that some of the
things you might use External Core for can now be done by using the GHC
API.
So the true answer to your title line Is External Core still
supported? is there is no reason it can't be, but in fact at the
moment it probably doesn't work right. I think this is a pity because
External Core is a pretty good way for people interested in analyses and
back ends to use GHC as a front end that translates all of Haskell into
a small intermediate language.
But all is not lost. External Core is a good example of a feature that
doesn't require deep knowledge of GHC's internals to understand and
maintain, so it's perfect for someone else to undertake.
Is anyone (or a group of people) interested?
We'd give plenty of support to such an effort.
Meanwhile, if you want to use External Core, but can't because it
doesn't work properly for you, don't be afraid to yell. (E.g. File a
Trac bug report.) I don't want to promise an immediate fix, but the
more people that use it the keener we are to get it done.
thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim
| Apple
| Sent: 11 October 2006 02:35
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] GHC Core still supported?
|
| In
http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html
| , I see two notes that I can't verify:
|
| 1. I don't see any CORE pragma on
| http://www.haskell.org/ghc/dist/current/docs/users_guide/pragmas.html
|
| 2. Using GHC 6.5.20060920, I compile
|
| module Core where
| data Foo = Bar
|
| with -fext-core to get
|
| %module main:Core
| %data main:Core.Foo =
| {Bar};
|
| I then compile the resulting hcr file with no flags to get
|
| no location info:
| 1: Parse error
| :
| %data main:Core.Foo =
| {Bar};
|
| Jim
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
| So, my hypothesis is that the inliner doesn't recognise that
| ``if (x = 0) then ...'' is effectively a case analysis on x, and thus
the
| argument discount is not fired. So we need to figure out how to
extend
| this criterion for when to apply the argument discount.
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
The relevant file is coreSyn/CoreUnfold.lhs, and the function is
calcUnfoldingGuidance.
I see some notes there with primops, namely:
PrimOpId op - primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map
arg_discount args)
-- At one time I tried giving an arg-discount
if a primop
-- is applied to one of the function's
arguments, but it's
-- not good. At the moment, any unlifted-type
arg gets a
-- 'True' for 'yes I'm evald', so we collect
the discount even
-- if we know nothing about it. And just
having it in a primop
-- doesn't help at all if we don't know
something more.
At the call site, the call
f x y
gets f's arg-discount for x if x is evaluated. But in the case of
primitive types we don't just want evaluated, we want to know the
value. So one could refine that. The relevant function is
interestingArg in simplCore/SimplUtils.
| (This whole idea of argument discounting seems rather ad hoc. Is it
not
| possible try out an inline, and remove it if in the end it doesn't get
| reduced in size sufficently?)
Yes, you could try that too. It might result in a lot of wasted work,
but it'd be a reasonable thing to try. The relevant code is in
simplCore/Simplify.lhs
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote:
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
Do you think it should be that general? I was thinking the discount
should only apply in the situtation where a case expression contains an
expression with one free varaible that is a function argument, and all
operations are primitive.
So I was thinking the right place to patch is in sizeExpr:
size_up (Case (Var v) _ _ alts)
| v `elem` top_args
= ...
And make this branch activate is a wider range of circumstances. SamB
is/was working on such a patch.
But making sure that all operations are primitive is not quite right, for
instance in
f :: Int - ...
f x | gcd x 21 1 = ...
we cannot give x an argument discount because (gcd (5::Int) 21) is not
rewritten into 1 (for some strange reason).
So, is there a way of deciding if a primitive op will be rewritten if all
its arguements are given?
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
| Do you think it should be that general? I was thinking the discount | should only apply in the situtation where a case expression contains an | expression with one free varaible that is a function argument, and all | operations are primitive. Well, if you see x =# 0 then it'd be good to inline if argument x was bound to a literal, even if the = is not scrutinised by a case. Why? Because then we can constant-fold it away. But perhaps the discount should be smaller? | So, is there a way of deciding if a primitive op will be rewritten if all | its arguements are given? The constant-folding rules for the primops are all in prelude/PrelRules.lhs in function primOpRules. Please add more rules. For example, I see that x +# 0 = x is not in there! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote: The constant-folding rules for the primops are all in prelude/PrelRules.lhs in function primOpRules. Please add more rules. For example, I see that x +# 0 = x is not in there! It is in libraries/base/GHC/Base.lhs x# +# 0# forall x#. x# +# 0# = x# -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: [Haskell] Expecting more inlining for bit shifting
Hello Simon,
Wednesday, October 11, 2006, 2:23:59 PM, you wrote:
The constant-folding rules for the primops are all in
prelude/PrelRules.lhs
in function primOpRules. Please add more rules. For example, I see
that
x +# 0 = x
is not in there!
but GHC.Base contains
{-# RULES
x# +# 0# forall x#. x# +# 0# = x#
0# +# x# forall x#. 0# +# x# = x#
x# -# 0# forall x#. x# -# 0# = x#
x# -# x# forall x#. x# -# x# = 0#
x# *# 0# forall x#. x# *# 0# = 0#
0# *# x# forall x#. 0# *# x# = 0#
x# *# 1# forall x#. x# *# 1# = x#
1# *# x# forall x#. 1# *# x# = x#
#-}
is this not enough?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 6.6
=== The (Interactive) Glasgow Haskell Compiler -- version 6.6 === The GHC Team is pleased to announce a new release of GHC. There have been many changes since the 6.4.2 release. For details, see the release notes here: http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
Simon Peyton-Jones simonpj at microsoft.com writes:
| So, my hypothesis is that the inliner doesn't recognise that
| ``if (x = 0) then ...'' is effectively a case analysis on x, and thus
the
| argument discount is not fired. So we need to figure out how to
extend
| this criterion for when to apply the argument discount.
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
The relevant file is coreSyn/CoreUnfold.lhs, and the function is
calcUnfoldingGuidance.
Actually it is sizeExpr. (Even so, apparantly I've been figuring this out the
hard way...)
The brach that currently handles these is the
size_up (Case e _ _ alts) = nukeScrutDiscount (size_up e) `addSize`
foldr (addSize . size_up_alt) sizeZero alts
branch. I've got a patch that seems like it ought to do a bettter job, but it
doesn't seem to give the $wrotate functions any discount (the $wshift functions
having been tagged by the {-# INLINE shift #-} pragmas I added all over).
Unfortunately I left it at home and I'm at school right now :-(.
It does get run sometimes, but I'm not sure if it is run for rotate or that its
results are kept...
I see some notes there with primops, namely:
PrimOpId op - primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map
arg_discount args)
-- At one time I tried giving an arg-discount
if a primop
-- is applied to one of the function's
arguments, but it's
-- not good. At the moment, any unlifted-type
arg gets a
-- 'True' for 'yes I'm evald', so we collect
the discount even
-- if we know nothing about it. And just
having it in a primop
-- doesn't help at all if we don't know
something more.
At the call site, the call
f x y
gets f's arg-discount for x if x is evaluated. But in the case of
primitive types we don't just want evaluated, we want to know the
value. So one could refine that. The relevant function is
interestingArg in simplCore/SimplUtils.
I might point out that the current code would throw out those discounts (the
nukeSrutDiscounts in that case).
| (This whole idea of argument discounting seems rather ad hoc. Is it
not
| possible try out an inline, and remove it if in the end it doesn't get
| reduced in size sufficently?)
Yes, you could try that too. It might result in a lot of wasted work,
but it'd be a reasonable thing to try. The relevant code is in
simplCore/Simplify.lhs
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] GHC Core still supported?
Hi,
I was just talking yesterday with a group of other students about
using the ExternalCore data type as the starting point for a project
we're starting to work on with the goal of having more practice
implementing various compiler components.
We were also talking about the possibility of using GHC as a sort of
front-end for this project, down the line, by having it emit external
core.
Even if we don't end up using it, I think it's a nice feature to
have, and I've been wanting to get involved in GHC development. So,
I'm volunteering to be at least one of the people to help get it up
to speed and keep it there.
Aaron
On Oct 11, 2006, at 12:47 AM, Simon Peyton-Jones wrote:
Jim, and others (I'm ccing GHC users)
External Core is a feature of GHC that is lonely and unloved.
External
Core longs to have someone to look after it, tell it that it is a
Truly
Useful Feature, and keep it working.
Seriously, External Core has a strong tendency to bit-rot because (so
far as I can tell) few people seem to use it, and hence it can lag
behind changes in the rest of the compiler. Yes, in principle we
at GHC
HQ should push the entire compiler along in sync, but there are
just too
few hours in the day. Another contributory factor is that some of the
things you might use External Core for can now be done by using the
GHC
API.
So the true answer to your title line Is External Core still
supported? is there is no reason it can't be, but in fact at the
moment it probably doesn't work right. I think this is a pity
because
External Core is a pretty good way for people interested in
analyses and
back ends to use GHC as a front end that translates all of Haskell
into
a small intermediate language.
But all is not lost. External Core is a good example of a feature
that
doesn't require deep knowledge of GHC's internals to understand and
maintain, so it's perfect for someone else to undertake.
Is anyone (or a group of people) interested?
We'd give plenty of support to such an effort.
Meanwhile, if you want to use External Core, but can't because it
doesn't work properly for you, don't be afraid to yell. (E.g. File a
Trac bug report.) I don't want to promise an immediate fix, but the
more people that use it the keener we are to get it done.
thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim
| Apple
| Sent: 11 October 2006 02:35
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] GHC Core still supported?
|
| In
http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html
| , I see two notes that I can't verify:
|
| 1. I don't see any CORE pragma on
| http://www.haskell.org/ghc/dist/current/docs/users_guide/
pragmas.html
|
| 2. Using GHC 6.5.20060920, I compile
|
| module Core where
| data Foo = Bar
|
| with -fext-core to get
|
| %module main:Core
| %data main:Core.Foo =
| {Bar};
|
| I then compile the resulting hcr file with no flags to get
|
| no location info:
| 1: Parse error
| :
| %data main:Core.Foo =
| {Bar};
|
| Jim
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Samuel Bronson wrote:
branch. I've got a patch that seems like it ought to do a bettter job,
but it doesn't seem to give the $wrotate functions any discount (the
$wshift functions having been tagged by the {-# INLINE shift #-} pragmas
I added all over). Unfortunately I left it at home and I'm at school
right now :-(. It does get run sometimes, but I'm not sure if it is run
for rotate or that its results are kept...
The problem with rotate is that it is:
(W32# x#) `rotate` (I# i#)
| i'# ==# 0# = W32# x#
| otherwise = W32# (narrow32Word# ((x# `shiftL#` i'#) `or#`
(x# `shiftRL#` (32# -# i'#
where
i'# = word2Int# (int2Word# i# `and#` int2Word# 31#)
The i'# gets inlined, so the case statement isn't actually actually doing
an analysis on i#, rather it is doing an analysis on
i# `and#` 31#.
So this lends support to SPJ's view that we need to check to see if a
variable is being used in an application of a primop that can be
evaluated, and all the other arguements are literals.
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Link errors when using the GHC API
Dear GHC hackers, I would like to experiment with the GHC API. However I get link errors when using it. For example: - $ ghci -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. ghc-6.6: /usr/lib/ghc-6.6/HSghc.o: unknown symbol `Cabalzm1zi1zi6_DistributionziPackage_a_closure' Loading package ghc-6.6 ... linking ... ghc-6.6: unable to load package `ghc-6.6' - I also get this when compiling for example the following module testGHC.hs: - module Main where import qualified GHC import DynFlags (defaultDynFlags) main = GHC.defaultErrorHandler defaultDynFlags $ putStrLn Hello World - - $ ghc -package ghc --make testGHC [1 of 1] Compiling Main ( testGHC.hs, testGHC.o ) Linking testGHC ... /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `r6iZ_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6r9_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sJ_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sN_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_zddEq_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6ID_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6IG_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo1_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x0): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1cc): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1dc): undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_closure' /usr/lib/ghc-6.6/libHSghc.a(PackageConfig.o): In function `s23t_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s77S_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s79E_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7i7_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7vI_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7yi_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_zeze_info' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7GC_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8TZ_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8Vv_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Finder.o): In function `s7l2_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' collect2: ld returned 1 exit status - I would like to know what is causing this and how I can fix it? Also, should I file a bugreport? Greetings, Bas van Dijk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Link errors when using the GHC API
Interesting. I was unable to reproduce your problem. What platform are you running on? Are you using a binary distribution or one you built from source? Seems like something didn't build right... You might use 'nm' to examine your libHSCabal.a to see if a similarly named symbol is present. For example, is there a leading underscore? May the version (m1zi1zi6) isn't present? On Oct 11, 2006, at 12:00 PM, Bas van Dijk wrote: Dear GHC hackers, I would like to experiment with the GHC API. However I get link errors when using it. For example: - $ ghci -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. ghc-6.6: /usr/lib/ghc-6.6/HSghc.o: unknown symbol `Cabalzm1zi1zi6_DistributionziPackage_a_closure' Loading package ghc-6.6 ... linking ... ghc-6.6: unable to load package `ghc-6.6' - I also get this when compiling for example the following module testGHC.hs: - module Main where import qualified GHC import DynFlags (defaultDynFlags) main = GHC.defaultErrorHandler defaultDynFlags $ putStrLn Hello World - - $ ghc -package ghc --make testGHC [1 of 1] Compiling Main ( testGHC.hs, testGHC.o ) Linking testGHC ... /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `r6iZ_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6r9_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sJ_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sN_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_zddEq_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6ID_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6IG_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo1_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x0): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1cc): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1dc): undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_closure' /usr/lib/ghc-6.6/libHSghc.a(PackageConfig.o): In function `s23t_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s77S_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s79E_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7i7_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7vI_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7yi_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_zeze_info' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7GC_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8TZ_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8Vv_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Finder.o): In function `s7l2_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' collect2: ld returned 1 exit status
ghc-6.6 candidate Win32 installer
Hi, for Win32 users wanting the latest GHC goodness, a candidate 6.6 installer is now available, http://haskell.org/ghc/dist/6.6/ghc-6-6.msi If anyone's willing to download it and kick the tires a bit, that'd be great. If nothing too egregious shows up, I'm planning to publish sometime tomorrow. thx --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
