> On Fri, 1 Aug 2003 12:51:21 +0100, you wrote:
> >>
> >> It is not empty and the entries look reasonable.
> >> > - Is there a discrepancy between leading underscores on the
> >> >symbols in libHSbase.a and the missing symbols?
> >> No; neither have any leading underscores.
> >Can you c
On Fri, 1 Aug 2003 12:51:21 +0100, you wrote:
>>
>> It is not empty and the entries look reasonable.
>> > - Is there a discrepancy between leading underscores on the
>> >symbols in libHSbase.a and the missing symbols?
>> No; neither have any leading underscores.
>Can you compile a small "
> >> It's a lower-case 'c'. Sorry - I typed it out by hand as
> the build is
> >> on a different machine.
> >
> >Could you check the following things:
> > - ghc/driver/package.conf: is it empty? Does it contain
> >reasonable-looking package entries?
>
> It is not empty and the entries
On Fri, 1 Aug 2003 12:38:09 +0100, you wrote:
>> It's a lower-case 'c'. Sorry - I typed it out by hand as the build is
>> on a different machine.
>
>Could you check the following things:
> - ghc/driver/package.conf: is it empty? Does it contain
>reasonable-looking package entries?
It is
> On Thu, 31 Jul 2003 13:57:02 +0100, you wrote:
> >> What is odd is that ghc-inplace is invoked by the make
> process several
> >> times before this big one (which appears to be the start
> of stage 2?)
> >> and works fine...
> >Do the errors really refer to "GHCziBase_True_Closure", or is it
On Thu, 31 Jul 2003 13:57:02 +0100, you wrote:
>> What is odd is that ghc-inplace is invoked by the make process several
>> times before this big one (which appears to be the start of stage 2?)
>> and works fine...
>Do the errors really refer to "GHCziBase_True_Closure", or is it
>"GHCziBase_True_c
> On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:
>
> >GHCziBase_True_closure is a symbol that should be coming
> from the base
> >package, the GHC.Base module in particular. You could check that
> >libraries/base/libHSbase.a looks reasonable: it should be on
> the order
> >of 17Mb. Try 'nm'
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:
>GHCziBase_True_closure is a symbol that should be coming from the base
>package, the GHC.Base module in particular. You could check that
>libraries/base/libHSbase.a looks reasonable: it should be on the order
>of 17Mb. Try 'nm' on it, look for some
On Wed, Jul 30, 2003 at 06:01:22PM +0100, Simon Marlow wrote:
>
> > stage2/utils/Util.o(.text+0xb8): In funtion "r4c8_entry": undefined
> > reference to "GHCziBase_True_Closure"
> >
> > ... and roughly 40,000 errors of the same form.
>
> GHCziBase_True_closure is a symbol that should b
> I am presently trying to build GHC on an i386 Linux box running
> debian/sid. (Yea, I know there's a .deb - in fact, I have it
> installed - but I need to be able to compile my own.)
>
> I've run configure and make, and stage 1 went quite well although
> there were a few syntax problems (usua
Hi folks,
I am presently trying to build GHC on an i386 Linux box running
debian/sid. (Yea, I know there's a .deb - in fact, I have it
installed - but I need to be able to compile my own.)
I've run configure and make, and stage 1 went quite well although
there were a few syntax problems (usually
11 matches
Mail list logo
