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 <ema...@freebsd.org> wrote:
> On 5 August 2017 at 16:16, Dimitry Andric <d...@freebsd.org> 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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"