thanks,
As this occurred while bootstrapping from .hc files, there are no .hi
files built yet.
-reilly hayes
On May 12, 2006, at 7:57 PM, Esa Ilari Vuokko wrote:
On 5/13/06, Reilly Hayes <[EMAIL PROTECTED]> wrote:
Hi
I suspect today's problem is pretty easy to figure out for a GHC
exper
Simon, how do you want to proceed with this? Just add
-fno-builtin-strlen to the .hc bootstrappping CC flags?
-- Don
rfh:
> Gentlemen,
>
> ghc -v was not required, as I am building this using .hc files from
> another host. Adding "-fno-builtin" to the CC opts did resolve the
> problem. Fur
On 5/13/06, Reilly Hayes <[EMAIL PROTECTED]> wrote:
Hi
I suspect today's problem is pretty easy to figure out for a GHC
expert, but I'm not. When I try to build utils/genapply, the link
fails because the symbols _GHCziList_lvl22_closure and
_GHCziList_zdwlen_info are undefined. I'll include th
I'm continuing in my quest to produce a clean build of GHC for Mac
intel. I'm using registerised .hc files built on 386 linux.
I suspect today's problem is pretty easy to figure out for a GHC
expert, but I'm not. When I try to build utils/genapply, the link
fails because the symbols _GH
Gentlemen,
ghc -v was not required, as I am building this using .hc files from
another host. Adding "-fno-builtin" to the CC opts did resolve the
problem. Furthermore, I believe I have confirmed that strlen is the
problem by succesfully compiling the library using "-fno-builtin-
strlen"
Friends,
A couple of weeks ago Simon M advertised the possibility that he and I
might run a "GHC Hackathon", in Portland, later this year prior to ICFP
(Sept 14-16 or thereabouts). The idea is that we'd give an extended
tutorial about GHC's glorious innards. Then we'd have some hacking time
in w
Bulat Ziganshin wrote:
moreover, afaiu, this means that ghc-compiled programs will no more
stall for several seconds doing major GC that is also very important
for any user-interactive program (especially games :) )
Unfortunately it won't completely remove the latency of a major GC,
although
Hello Simon,
Wednesday, May 10, 2006, 4:12:18 PM, you wrote:
> The GC is currently single-threaded, but we have an intern who started
> here this week (Roshan James) who is working on a parallel
> implementation of the GC.
GREAT! if you browse Intel/AMD news, you should know that they plan to
d
john:
> On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
> > >Especially since even:
> > >
> > >checking Haskell type for intmax_t... not supported
> > >checking Haskell type for uintmax_t... not supported
> > >
> > >aren't universal :)
> >
> > Well, yes. Any suggestions for
On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
> >Especially since even:
> >
> >checking Haskell type for intmax_t... not supported
> >checking Haskell type for uintmax_t... not supported
> >
> >aren't universal :)
>
> Well, yes. Any suggestions for what to do here? Make a
I'm pretty sure this is to do with calls to strlen() from Data.ByteString.
Can you check for sure that gcc is being passed -fno-builtin? (use ghc -v).
Failing that, we might have to use a private version of strlen() that
gcc doesn't try to inline.
Cheers,
Simon
Reilly Hayes wrote:
Donald Bruce Stewart wrote:
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know whic
simonmar:
> On 12 May 2006 00:47, John Meacham wrote:
>
> > On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
> >> On the other hand, keeping intermediate Doubles to 80-bit precision
> >> is both (a) non-portable and (b) unpredictable (the programmer
> >> doesn't know which intermediat
On 12 May 2006 00:47, John Meacham wrote:
> On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
>> On the other hand, keeping intermediate Doubles to 80-bit precision
>> is both (a) non-portable and (b) unpredictable (the programmer
>> doesn't know which intermediates are going to be sto
14 matches
Mail list logo
