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 there??) 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. > -- Best Regards, Aijaz Baig _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
