That was some pretty relevant information Ed. Thanks.

However upon bumping up my RAM, I don't hit this error anymore perhaps I
believe since the relatively large amount of RAM does not necessitate that
much of swap space.

Nonetheless, as I have indicated in my previous email, I hit an error quite
late in the process now (stage 4.3) when it is apparently linking  h_raw.o
into h_raw.full ( is this linking by the way? what is the .full file

Keen to hear

On Sun, Aug 6, 2017 at 3:04 PM, Ed Maste <> wrote:

> On 5 August 2017 at 16:16, Dimitry Andric <> wrote:
> >
> > I remember there being an issue with ar and/or ranlib choking when the
> > .a files become too big.  Ed, does that ring any bells?
> Our ar (and ranlib, which is the same binary) will produce a corrupt
> symbol table if the .a archive output is larger than 4GB, because we
> support only 32-bit offsets in the older "/" symbol table format, not
> the "/SYM64/" format and 64-bit offsets.
> As with GNU ar from binutils 2.17.50 we silently truncate if the
> offset does not fit in 32 bits. I'll have a patch for review soon to
> exit on error rather than produce corrupted output, and hope to look
> at adding /SYM64/ support later on.


Best Regards,
Aijaz Baig
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to